Forum Discussion
MicrosoftWorkaround for non-responsive Windows 10 Enterprise multi-session hosts
Some Windows Virtual Desktop customers are recently affected by non-responsive Windows 10 Enterprise multi-session hosts. We have identified two issues, one related to a deadlock within FSLogix and one where a weekly BiSrv cleanup task exhausts system resources.
In both scenarios Windows Virtual Desktop diagnostics show VMs in a "NoHeartBeat" state.
We recommend to take the following actions:
- Upgrade FSLogix to the latest version using this link. This update contains a fix for a deadlock regression in version 2.9.7205.27375 of frxdrvvt.sys .
- While we are working on an update for the BiSrv issue, which will be available through Windows Update, we recommend to temporarily disable the scheduled BgTaskRegistrationMaintenanceTask.
This can be done by either:
- Signing into Windows, clicking the Windows button, searching for "Task Scheduler", navigating to \Microsoft\Windows\BrokerInfrastructure, right clicking the BgTaskRegistrationMaintenanceTask and selecting "disable".
- Sign into Windows, click the Windows button, search for "command line", right click it, select "Run as Administrator", and run the following command:
schtasks /change /tn "\Microsoft\Windows\BrokerInfrastructure\BgTaskRegistrationMaintenanceTask" /disable
Update: a fix for the BiSrv issue is made available as part of the latest cumulative update. This will also re-enable the scheduled task if the workaround was applied.
- Hi Pieter, are you able to elaborate on those scenarios? We did have a lot of trouble with our previous host pool vms becoming unresponsive and need to determine if we have to disable this task on our current vm's.
- PieterWigleven
sbuntun The BgTaskRegistrationMaintenanceTask scheduled task runs every 7 days and cleans up cached data that a service called BiSrv has for each user profile that was deleted.
If you have "enough" user profiles deleted within those 7 days, the system might run out of worker threads resulting in the WVD agent to be impacted.
Anything that deletes user profiles after user logoff will accelerate this, including FSLogix which by default deletes the profile during logoff. I don't have data yet to provide more details on how many profiles would qualify as "enough".
Hope this information helps you understand which scenarios this issue would surface in.
This happened to my hosts. I upgraded FSLogix from FSLogix_Apps_2.9.7205.27375 to FSLogix_Apps_2.9.7237.48865 and it seemed to have fixed it. I am going to implement the next fix per this post. Thank goodness I found this discussion. My hosts are production and got real users.
Is there any update when the fix will be in Windows Update for the BiSrv issue?
- PieterWiglevenIt will be part of the cumulative update in March on patch Tuesday. You can safely disable the scheduled task until that time. The same update will enable to scheduled task for those organizations that applied the workaround.
