Two Azure Virtual Desktop session hosts running Windows 11 24H2/25H2 on D16s_v5 VMs in Australia Southeast had been stable since July, but over the past few weeks both have intermittently become completely unresponsive. The incidents occur even with very few users connected, so the problem does not appear to be caused by workload.
When a freeze occurs, users are disconnected or unable to sign in, RDP and Bastion stop responding, the serial console is inaccessible, and Azure continues to report the VM as running. Azure Monitor telemetry also stops at the same time. Some incidents clear after about an hour, while others require a restart from the Azure portal.
Immediately before one outage, more than 17 DCOM components failed to register within a few seconds, the FSLogix service hung for roughly 30 seconds, and then the system logged disk Event 51 errors stating that an error occurred during a paging operation. A similar disk error appeared on the other host during a separate incident. The hosts use Premium SSD managed disks.
FSLogix, antivirus exclusions, the AVD agent, required service endpoints, and the known RDS patch issue have already been checked or updated. IOPS did not appear to be throttled; usage peaked around 400–500 IOPS against a disk limit of about 1,100 IOPS. The hosts sit behind a Meraki vMX used for SD-WAN, and Microsoft support has an open high-severity case, but there has not been much progress.
Has anyone experienced complete AVD host freezes like this, particularly alongside Event 51 disk errors? Would rebuilding or redeploying a host be the best way to test for an underlying Azure hardware issue?
4 Answers
Do not completely dismiss the network path just because the required endpoints pass their tests. Since both hosts use a Meraki vMX for SD-WAN, check its logs, tunnel health, packet loss, latency, and any connection or inspection limits during the outages. Also verify whether the issue affects only users connecting from Australia Southeast or whether the host itself loses connectivity from Azure management services. A filtering or inspection device interfering with HTTPS check-ins could make a host appear healthy until it suddenly stops responding.
The Event 51 paging errors are the strongest clue here. I would focus on the storage path before chasing the DCOM failures, since those may simply be fallout from the host becoming unhealthy. Compare disk-level and VM-level IOPS, throughput, latency, and burst metrics at the exact freeze times. If the numbers are normal, redeploy one session host from the same image so it lands on different Azure infrastructure. That gives you a better hardware comparison than repeatedly restarting the existing VM.
The disks were only reaching around 400–500 IOPS, well below their 1,100-IOPS limit, so throttling did not stand out. Redeploying one host to test different underlying hardware is probably the next step.
A clean rebuild is worth trying, especially if the issue follows the VM rather than the image. Create a replacement host with the same configuration and image, leave the original available for comparison, and see whether the replacement develops the same disk errors. If both hosts continue to fail, investigate the shared configuration or infrastructure path instead of treating it as an isolated VM problem.
I have not rebuilt either host yet, but that sounds like a useful way to separate an image problem from an underlying Azure host or disk problem.
The burst of DCOM registration failures and the FSLogix timeout may be symptoms rather than the cause. Correlate the Windows System log, storage latency, Azure Activity Log, VM host events, and network telemetry by timestamp. If the guest stops producing telemetry while the portal still says Running, ask Microsoft to check platform-level host and disk health and consider moving the VM to new infrastructure rather than relying on an in-place restart.
The environment has no web content-filtering product and only one main business application, but I had not yet checked the vMX closely during an incident. I will review its tunnel and connection logs.