none
Windows 10 1709: KB4054022 Might be breaking App-V Client (fixed) RRS feed

  • Question

  • I am investigating, but I wanted to give a heads up to others possibly looking at this as well.  This issue has not been confirmed to me by Microsoft and it is possible there is something else going wrong on these machines that I have not yet found, but this is big enough to give an early heads up in case others are experiencing the same issue.

    Fortunately folks are not (generally) using 1709 in production yet.

    Symptoms: After receiving the November "servicing stack update" for Win10 1709 (KB4054022) https://support.microsoft.com/en-us/help/4054022/servicing-stack-update-for-windows-10-version-1709-november-30-2017

    the App-V client stops working.  Furthermore, you can see but cannot uninstall the update via add/remove programs (updates section).

    Details on the symptoms include:

    • Most App-V cmdlets do not work at all, a few do.
    • You cannot add/remove/publish/unpublish or run any App-V packages.
    • Get-AppvStatus reports that the client is enabled and does not require a reboot.
    • The App-V Client windows service is present, but stopped.
    • Attempts to manually start the App-V Client windows service fails with error 1068 (failure on a dependency).
    • fltmc reports that only one of the App-V drivers is loaded (AppVStrm).  AppVVFS (which appears to be the cause of the dependency failure) is missing, as is AppVVeMgr.  These driver's files are present on the system and registered in the registry.

    As we cannot uninstall the KB once added to the system, there is no known workaround at this time.

    I'll update this as I learn more, but if others have information please reply to this post as well.


    Tim Mangan MVP for App-V and Citrix CTP Author of AppV books: "PowerShell with App-V 5 (5.1 Edition)", "The Client Book (4.x)" and "OSD Reference Book" (http://www.tmurgent.com/Books )


    Thursday, December 14, 2017 1:31 PM
    Moderator

Answers

  • OK. So here is the story...

    The issue only occurred for machines receiving both 4054022 and 4054517 at the same time.  That 4054022 (the servicing update) has no uninstall made this a little harder to track down. As these were VMs with a checkpoint that was offline for a few weeks, they were receiving both.

    It seems that as of around mid day (EST) yesterday, Microsoft must have made a change in the update filtering such that if 4054517 is in the list that 2054022 no longer appears, and this resolves the problem.

    Having both is not an issue, I can manually add 4054022 and then perform the update. This was strictly a timing issue when both are occurring via updates due to the background TIworker process and reboot timing. I don't think customers will run into this issue if they didn't already have it.


    Tim Mangan MVP for App-V and Citrix CTP Author of AppV books: "PowerShell with App-V 5 (5.1 Edition)", "The Client Book (4.x)" and "OSD Reference Book" (http://www.tmurgent.com/Books )


    Friday, December 15, 2017 1:53 PM
    Moderator

All replies

  • Information on unsuccessfully moving the bar...

    You can run (in an elevated window) "fltmc load appvvfs" to load that driver, which allows the App-V client to be able to attempt to be started. 

    Doing the same with the appvvemgr driver either fails to find it (if done before appvvfs) or says it is already running if done after.  It still doesn't show in the fltmc command to show the loaded drivers, so there might still be a problem here or this might be normal, I don't know.

    After loading the AppVVFS driver, trying to starting the client fails and both in logging and get-appvstatus we can see that the client now thinks it needs a reboot.

    After a reboot, I can start the appvvfs driver again and now when I try to start the client service it gets further along (as seen in client debug log) and fails with error 0x23F, which just indicates that a process failed to start properly (useless). The App-V client did get far enough along to read it's configuration from the registry, but didn't log any real issues before giving up.

    Stay tuned...


    Tim Mangan MVP for App-V and Citrix CTP Author of AppV books: "PowerShell with App-V 5 (5.1 Edition)", "The Client Book (4.x)" and "OSD Reference Book" (http://www.tmurgent.com/Books )

    Thursday, December 14, 2017 3:02 PM
    Moderator
  • Tim - I have .1709 on my Surface Pro and have confirmed the KB is installed and no problems with App-V client I am afraid.

    Thursday, December 14, 2017 4:34 PM
  • Thanks for that Andrew.  I'll have to backtrack on another system to try to find the cause.  These are VMs on Hyper-V so that may be important...

    Tim Mangan MVP for App-V and Citrix CTP Author of AppV books: "PowerShell with App-V 5 (5.1 Edition)", "The Client Book (4.x)" and "OSD Reference Book" (http://www.tmurgent.com/Books )

    Thursday, December 14, 2017 4:37 PM
    Moderator
  • Hello Tim,

    Just like Andrew, no issues with Win10 v1709 machines (KB4054022 installed). We have some 1709 machines in production, no issues reported yet. 

    Thursday, December 14, 2017 8:57 PM
  • I have found the issue on three machines so far.  It seems to not  be always repeatable and I'm beginning to suspect a timing issue in how updates are applied. 

    It may be related to discovering both 4054022 and 4054517 available at the same time.  4054022 does work during a necessary reboot, but there might be a delayed process (TIWorker) involved that runs asynchronously. 405417 doesn't install until after that reboot, and I'm still not sure which one the TIWorker that I saw was related to.  When the issue happens, it doesn't hit until after a reboot after the TIWorker completes.  I'm still trying to isolate but I am learning that success in an attempt may not prove out that attempt as things are happening in the background that I didn't expect. 

    More updates when I know more.


    Tim Mangan MVP for App-V and Citrix CTP Author of AppV books: "PowerShell with App-V 5 (5.1 Edition)", "The Client Book (4.x)" and "OSD Reference Book" (http://www.tmurgent.com/Books )

    Thursday, December 14, 2017 9:05 PM
    Moderator
  • Tim,

    We used 1709 clients in the class last week right? Those machines probably doesn't had KB4054022 applied?

    Thursday, December 14, 2017 9:24 PM
  • Yes, and they did not have either update at that time, even though 4054022 could have been applied if I had let it.  The issue was seen on some of those VMs which were reverted to the same snapshot you received and allowed updates.

    Tim Mangan MVP for App-V and Citrix CTP Author of AppV books: "PowerShell with App-V 5 (5.1 Edition)", "The Client Book (4.x)" and "OSD Reference Book" (http://www.tmurgent.com/Books )

    Thursday, December 14, 2017 9:29 PM
    Moderator
  • Tim,

    You're using SCS on those machines if i remember correctly. We're not using SCS on our machines and have no issues (so far). Worth to test it?

    Friday, December 15, 2017 10:24 AM
  • OK. So here is the story...

    The issue only occurred for machines receiving both 4054022 and 4054517 at the same time.  That 4054022 (the servicing update) has no uninstall made this a little harder to track down. As these were VMs with a checkpoint that was offline for a few weeks, they were receiving both.

    It seems that as of around mid day (EST) yesterday, Microsoft must have made a change in the update filtering such that if 4054517 is in the list that 2054022 no longer appears, and this resolves the problem.

    Having both is not an issue, I can manually add 4054022 and then perform the update. This was strictly a timing issue when both are occurring via updates due to the background TIworker process and reboot timing. I don't think customers will run into this issue if they didn't already have it.


    Tim Mangan MVP for App-V and Citrix CTP Author of AppV books: "PowerShell with App-V 5 (5.1 Edition)", "The Client Book (4.x)" and "OSD Reference Book" (http://www.tmurgent.com/Books )


    Friday, December 15, 2017 1:53 PM
    Moderator