Two Azure Virtual Desktop session hosts (D16s_v5 running Windows 11 24H2/25H2 in Australia Southeast) have started becoming completely unresponsive after running normally since July. The freezes began a few weeks ago and have happened several times, even when only a few users were connected, so it does not appear to be a capacity issue.
During an incident, users are disconnected or unable to sign in, RDP and Bastion stop responding, the serial console is unavailable, and Azure Monitor telemetry goes silent. The Azure portal continues to show the VM as Running. Sometimes the host recovers after about an hour, but usually it needs to be restarted from the portal.
Shortly before one failure, more than 17 DCOM components failed to register within a few seconds, the FSLogix service hung for around 30 seconds, and then the system logged disk hardware errors, including Event ID 51: "An error was detected during a paging operation." The same disk error has appeared on the other host during a separate incident. Both hosts use Premium SSD managed disks.
FSLogix, the AVD agent, antivirus exclusions, required service endpoints, and the known September Remote Desktop Services update issue have already been checked or addressed. A high-severity Microsoft support case is open, but there has not been much progress yet. Has anyone seen AVD hosts fail this way, or found a reliable way to determine whether the underlying Azure host or storage is at fault?
3 Answers
It is still worth checking whether the problem lines up with a regional network or connectivity issue, especially since most users connect from Australia Southeast. Compare the affected hosts with another host or region and review bandwidth, latency, packet loss, and connection activity during the incidents. That said, the storage-related Event 51 errors and the complete loss of the serial console make a guest network problem less likely than a VM, storage, or host-level failure.
Rebuilding one of the hosts from the known-good image would be a worthwhile isolation test. If the newly deployed host remains stable while the existing one continues freezing, that points toward the VM or underlying host rather than the image or application. Also review the Meraki vMX path and any Azure or third-party firewall rules, since the hosts depend on persistent HTTPS connectivity for management and check-in.
The Event 51 paging errors stand out more than the DCOM failures. Check the VM-level and disk-level IOPS, throughput, latency, and queue metrics at the exact time of each freeze. If the disks are not being throttled, redeploy one session host instead of simply restarting it. A fresh deployment may move it to different underlying Azure hardware and give you a useful comparison.
I checked the IOPS and they did not appear to be throttled. The disks were peaking around 400–500 IOPS, while their limit is about 1,100. It still feels more like an Azure hardware problem that the portal is not exposing.
I have not rebuilt the hosts yet, but that is probably the next practical test. They do sit behind a Meraki vMX for site-to-site connectivity, so I will check that path as well. There is no web content-filtering service in the environment.