Two Azure Virtual Desktop session hosts running on D16s_v5 VMs in Southeast Azure have been stable since July but started freezing intermittently about two or three weeks ago. The hosts are running Windows 11 24H2/25H2 with Premium SSD managed disks, and the incidents happen even when very few users are connected.
When a freeze occurs, users are disconnected or unable to sign in, RDP and Bastion stop responding, the serial console is unavailable, and the Azure portal continues to show the VM as running. Azure Monitor telemetry also stops reporting. Sometimes the host recovers after about an hour, but usually it needs to be restarted from the portal.
Immediately before one incident, more than 17 DCOM components failed to register within a few seconds, the FSLogix service became unresponsive for roughly 30 seconds, and Windows logged Event 51 disk errors stating that an error occurred during a paging operation. The same disk error has appeared on the other host during a separate incident.
FSLogix, antivirus exclusions, the AVD agent, required network endpoints, and a known RDS patch issue have already been investigated or addressed. Both hosts have the relevant hotfix installed, and a critical support case is open with Microsoft, but there has not been much progress. Has anyone experienced similar complete freezes or found a reliable way to identify the underlying cause?
4 Answers
It may still be worth checking the FSLogix profile container quota and disk capacity, even if the service version is current. We ran into instability after the FSLogix disk quota was exhausted, and the symptoms were not always obvious at first.
A Windows update appeared to trigger similar freezes in another environment. Disabling the Windows Search service on the session hosts stopped the lockups completely, although users lost local Windows Search functionality. Outlook search continued to work through cloud search. Since your users only run a single remote application, temporarily disabling Windows Search on one test host could be a reasonable A/B test rather than changing every host at once.
We previously saw unexplained instability across several session hosts that seemed related to the image or update state. Rebuilding one host from an earlier golden image, applying updates manually, and comparing it with the affected machines made the errors disappear. Even though automatic updates were disabled, something in the update or image process may have left the hosts in a bad state, so testing a clean rebuilt host could help isolate it.
Event 51 during a paging operation on both hosts, combined with Bastion and the serial console becoming unavailable, makes an issue in the OS disk or VM storage path more likely than a normal AVD or user-load problem. Check Azure metrics for the exact incident windows, especially OS Disk IOPS Consumed Percentage, OS Disk Bandwidth Consumed Percentage, and the VM's cached and uncached IOPS percentages. Also review Resource Health for both VMs during those periods.
For the next occurrence, configure a kernel memory dump and enable NMI crash handling with NMICrashDump under HKLMSYSTEMCurrentControlSetControlCrashControl. If the serial console becomes available long enough, trigger an NMI before restarting the VM. Analyzing the dump with commands such as !stacks and !irpfind may show which driver is waiting on stalled I/O, including a possible FSLogix driver issue.
Thanks, I’ll set this up so we can capture better evidence if it happens again.
That may be worth testing on one host, since our users mainly use a single remote application.