Two AVD session hosts running on D16s_v5 VMs in Southeast Azure have started locking up intermittently after working normally since July. They run Windows 11 24H2/25H2, use Premium SSD managed disks, and have very few active users when the incidents occur, so this does not appear to be a workload issue.
When a freeze happens, users are disconnected or cannot sign in, RDP and Bastion stop responding, the serial console is unavailable, and Azure continues to show the VM as Running. Monitoring telemetry also stops at the same time. Sometimes the host recovers after about an hour, but usually it needs to be restarted from the Azure portal.
Just before one incident, more than 17 DCOM components failed to register within a few seconds, the FSLogix service hung for roughly 30 seconds, and Windows logged Event 51 indicating an error during a paging operation. The other host has logged similar disk errors during a separate incident.
FSLogix and the AVD agent are up to date, antivirus exclusions have been corrected, required endpoints pass validation, and the known RDS patch issue and hotfix have already been addressed. A high-priority Microsoft support case has not produced much progress yet.
Has anyone dealt with this kind of complete host freeze, especially with Event 51 and FSLogix activity immediately beforehand? What diagnostics would you collect to determine whether this is a managed-disk problem, a Windows driver issue, or something related to FSLogix or a recent update?
4 Answers
If the investigation keeps pointing to updates rather than infrastructure, try rebuilding one host from a known-good golden image instead of repeatedly repairing the existing machine. Apply the current updates manually and compare the behavior with the affected hosts. We had a similar situation where the errors disappeared after restoring an earlier image and reinstalling updates, even though automatic updating was disabled. It was not a satisfying root cause, but it helped isolate whether the existing OS installation had become inconsistent.
A Windows update may be involved, especially if the failures started after the July update cycle. One workaround that helped us was disabling the Windows Search service on the session hosts. It reduced the freezes completely in our environment, although users lost local Windows Search functionality; cloud-backed Outlook search still worked. Since your users only run a single remote application, testing this on one host could be relatively low risk.
The combination of Event 51 during paging, both hosts showing similar symptoms, and even the serial console becoming unreachable points more toward an I/O path stall than an ordinary AVD or session-load problem. Pull Azure metrics for the exact incident windows, including OS disk IOPS consumed percentage, OS disk bandwidth consumed percentage, and the VM's cached and uncached IOPS percentages. Resource Health records for those timestamps may also show whether Azure detected an underlying platform issue.
For the next occurrence, configure a kernel memory dump and enable NMI crash-dump handling with NMICrashDump under HKLMSYSTEMCurrentControlSetControlCrashControl. If the serial console becomes available long enough, trigger an NMI before restarting the VM. Examining the dump with commands such as !stacks and !irpfind may reveal whether a storage or FSLogix driver is holding I/O indefinitely.
Thanks, I’ll set this up so we can capture something useful during the next freeze instead of immediately rebooting the host.
It is also worth checking FSLogix profile-container quotas and free space. We have seen quota exhaustion cause services and profile operations to behave badly, even when the hosts were not under much CPU or memory pressure. I would verify the quota, storage account health, container growth, and available space rather than focusing only on the FSLogix version.
That may be worth trying on one host. Our users mainly use one remote app, so losing local Windows Search would probably be manageable as a controlled test.