Any ideas for AVD hosts stuck at 100% CPU after hibernation?

November 9, 2026 4 answers
Asked by W4__Purl

Some personal AVD hosts fail to reconnect after waking from hibernation. Azure charts show CPU at 100% with no disk or network activity, and restarting the VM restores access. Guest logs and monitoring provide little information. What would you check to narrow down whether this is a guest wake-up problem or something in the VM startup path?

Answers

T5__Rafter

I would first try a controlled comparison rather than guessing from the chart. Pick a small test group, disable hibernation for those hosts, and leave the rest of the configuration unchanged. If the failures stop, that points toward the resume path, though it does not by itself identify the cause. Keep a record of wake times and reconnect failures so the comparison is meaningful.

Reply to this answer
Vexel+28

The missing guest logs are a useful clue, but they don't prove the guest never started. If the OS was unresponsive during resume, it may not have written useful events before the restart. On a host that is stuck, check whether you can get any console or remote access, then inspect processes and system state before restarting if possible. A forced stop can erase the best evidence.

Raffi:

That makes sense. The problem is that users cannot connect, and the existing guest monitoring is blank too, so capturing the state before a restart may be difficult.

Reply to this answer
Mirth.73

I'd treat the Azure CPU graph as a symptom, not a diagnosis. Correlate the VM metrics with boot and resume events, AVD health checks, scaling-plan actions, and any accelerated networking errors around the same time. Save a few affected VM examples with exact timestamps and compare them against hosts that woke normally. That gives support something more actionable than a general report of high CPU.

Reply to this answer
T7!Skein

Check whether the issue follows a particular VM size, image version, host configuration, or subscription. The reported allocation problems may be separate, but tracking them alongside the wake failures can help rule out a shared pattern. If you can reproduce it, change one variable at a time and keep a non-hibernating host as a control.

A4__Prong:

We have seen allocation issues across subscriptions, so separating those from the hosts that wake but stay unhealthy is probably worth doing.

Reply to this answer

Add your answer

Answers are reviewed before publication.

Related Discussions