Some links on this page are affiliate links: if you buy through them we may earn a commission, at no extra cost to you.
Microsoft’s documented Windows Server 2022 Hyper-V freeze-and-restart issue primarily affected confidential VMs, especially Azure confidential VMs—not every Hyper-V VM. Microsoft fixed that defect in the May 23, 2025 out-of-band update KB5061906 (OS Build 20348.3695); later cumulative updates include the fix. In 2026, install the latest applicable, approved Windows Server 2022 cumulative update rather than treating KB5061906 as the current target. If an ordinary VM freezes, diagnose the host, guest, storage, network, checkpoints, and backup activity before attributing it to Hyper-V.
First decide whether Microsoft’s known issue applies
Microsoft documented intermittent unresponsiveness or unexpected restarts in confidential VMs on Hyper-V. The affected path was the Hyper-V Platform direct-send path for a guest physical address. Microsoft said the issue primarily affected Azure confidential VMs. See the KB5061906 release notes.
Check these distinctions before applying that diagnosis:
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →- Confidential VM: The documented issue is relevant if the affected workload is a confidential VM. Confirm its type in the Azure or virtualization configuration; do not infer it from the guest OS.
- Ordinary Azure VM: Being hosted in Azure does not by itself mean the VM is confidential or affected by this defect.
- On-premises confidential VM: The defect concerns confidential workloads on Hyper-V, but Microsoft described Azure confidential VMs as the primary impact. Confirm your configuration and consult Microsoft if the symptoms match.
- Ordinary on-premises Hyper-V VM: A freeze or restart alone does not establish that this known issue applies. Follow the broader checks below.
- Windows Server 2022 host versus guest: The documented update is for the Windows Server 2022 host. A Windows Server 2022 guest running on a different host is not, by that fact alone, evidence of the host defect.
KB5061906 was released on May 23, 2025 as an out-of-band, non-security update and brought the OS to build 20348.3695. It is useful as a historical minimum-fix reference, not as a reason to install an obsolete standalone package on a host already receiving newer cumulative updates. Microsoft’s virtual machine troubleshooting guidance says later updates include the fix.
#1 Best Overall
Before powering off: preserve the incident evidence
A frozen console is not necessarily a frozen guest. Before resetting or turning off a VM, record:
- Host and VM names, and the exact incident time in UTC and local time.
- Whether the VM recovered by itself and whether it was running, paused, saved, reset, or forcibly powered off.
- Whether RDP, SSH, WinRM, ping, or the application still responded, and whether VMConnect showed a frozen screen.
- Whether other VMs on the host or cluster were affected.
- Recent host or guest updates, backup jobs, checkpoint creation or merging, migration, storage changes, and driver or firmware changes.
Repeated forced power-offs can cause guest filesystem or application-consistency problems, particularly while writes are in progress. That does not mean every forced shutdown corrupts a VHDX, but it is a reason to use forced power-off only when necessary and to preserve logs first when feasible.
Check the host’s Windows Server build and update level
Run these commands on the Hyper-V host from an elevated PowerShell session:
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
winver
systeminfo.exe | Select-String "OS Name","OS Version"
Get-ComputerInfo | Select-Object WindowsProductName, WindowsVersion, OsBuildNumber
Get-HotFix -Id KB5061906 -ErrorAction SilentlyContinue
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 20
DISM /Online /Get-Packages /Format:TableUse winver or Get-ComputerInfo to record the build. Get-HotFix is a quick check, but a cumulative update may supersede an earlier package, so absence of KB5061906 from that output does not alone prove the fix is missing. DISM’s package list and the host’s update history give additional servicing context. Compare the result with the latest applicable Windows Server 2022 update for the host’s architecture, servicing channel, and deployment method.
Normally, keep the host on the latest cumulative update approved by your organization. Do not install both KB5061906 and a newer cumulative update just because both are mentioned in an incident article; the newer cumulative update normally supersedes the older fix. Microsoft lists Windows Update, Windows Update for Business, Microsoft Update Catalog, and WSUS as update channels. For the original standalone OOB package, Microsoft directed administrators to the Microsoft Update Catalog. The May 2025 servicing guidance identifies KB5030216 or a later cumulative update as the minimum prerequisite in the referenced offline-servicing scenario; check the applicable package guidance before offline servicing. See Microsoft’s May 2025 servicing notes.
Apply the update without creating a second incident
- Confirm the host is recoverable from backup and arrange a maintenance window.
- Where possible, drain or migrate workloads using your normal cluster and change-management procedures.
- Install the latest approved, applicable Windows Server 2022 cumulative update through your normal servicing channel.
- Reboot the host if required by the update, then record and verify its build.
- Start or resume the affected VM and confirm guest access and application health.
- Keep update history and host and guest logs with the incident record, and monitor for recurrence.
If the VM is a confidential VM, the host is below the historical fixed build, and the symptoms match, prioritize patching through a safe change window. If ordinary VMs are involved, or the timing points to storage, backup, guest crashes, or host hardware, collect evidence and investigate those paths too; a patch should not substitute for diagnosis.
Classify what “freeze” or “restart” means
Note what is actually unavailable. These observations narrow the fault domain:
- Guest reachable, VMConnect frozen: The guest may still be working; investigate the console or management path as well as the VM.
- Guest unreachable, host responsive: Check guest logs, VM worker events, storage, and the VM’s resource state.
- Hyper-V Manager says “Running,” but operations time out: A running state does not prove the guest is healthy. Correlate VMMS and worker logs with guest and host evidence.
- VM is paused: Check the pause reason, available disk space, storage, and checkpoint or backup activity.
- One restart after patching: Review the update and reboot history before treating it as a repeating platform failure.
- Repeated unexpected restarts: Check guest bugchecks and restart events alongside host-side evidence.
- Host itself is unresponsive, or several VMs fail together: Prioritize host resources, storage, network, drivers, firmware, and cluster health.
Record whether one VM, several VMs on one host, or VMs on multiple hosts are affected. A single VM points toward its guest, virtual hardware, disk, or application. Multiple VMs on the same host suggest shared host resources or devices. Failures across hosts suggest shared storage, network, backup infrastructure, common updates, or—in an Azure confidential VM scenario—a platform dependency.
Collect host-side logs around the incident
In Event Viewer, review Windows Logs > System and, where present, Applications and Services Logs > Microsoft > Windows for Hyper-V-VMMS, Hyper-V-Worker, Hyper-V-Hypervisor, and Hyper-V-VmSwitch. Also inspect relevant Disk, StorPort, iSCSI, MPIO, network-adapter, and FailoverClustering logs. Log names and enabled channels vary by host and configuration.
To list available Hyper-V logs:
Get-WinEvent -ListLog '*Hyper-V*' |
Select-Object LogName, IsEnabled, RecordCountTo pull potentially relevant System events for the previous four hours:
Rank #3
- Mastering Active Directory: Design, deploy, and protect Active Directory Domain Services for Windows Server 2022, 3rd Edition
- ABIS BOOK
- Packt Publishing
$Start = (Get-Date).AddHours(-4)
$End = Get-Date
Get-WinEvent -FilterHashtable @{
LogName = 'System'
StartTime = $Start
EndTime = $End
} |
Where-Object {
$_.ProviderName -match 'Hyper-V|VMMS|Worker|Hypervisor|StorPort|Disk|iSCSI|MPIO|FailoverClustering|Tcpip|Net'
} |
Select-Object TimeCreated, ProviderName, Id, LevelDisplayName, Message |
Format-ListAdjust the time window to include the incident and any recovery. Do not treat a single event ID as proof of root cause. Correlate its timestamp with the guest, storage, network, backup, and cluster evidence, and note whether other VMs were affected.
Recommended Free Tools
Check the guest, not just the host
For a Windows guest, review System events from the same time window for Kernel-Power, EventLog, BugCheck, WindowsUpdateClient, Disk, Ntfs, volmgr, and Service Control Manager entries. For Linux, review the kernel log and system journal, as well as cloud-init logs where applicable.
Get-WinEvent -FilterHashtable @{
LogName = 'System'
StartTime = (Get-Date).AddHours(-4)
} |
Where-Object {
$_.ProviderName -match 'Kernel-Power|BugCheck|Disk|Ntfs|volmgr|WindowsUpdateClient|Service Control Manager'
} |
Select-Object TimeCreated, ProviderName, Id, LevelDisplayName, Message |
Format-ListA guest Kernel-Power event commonly records that a shutdown was unexpected; it does not identify the cause. A bugcheck and dump may point toward a guest OS or driver failure. Guest storage errors can make a guest appear hung. Conversely, a lack of useful guest events alongside host-side Hyper-V errors can support investigation of the host or virtualization layer, but does not prove that is the cause.
Use the scope of the outage to choose the next checks
If only one VM is affected
Inspect that VM’s memory pressure, Dynamic Memory configuration, processor allocation, VHDX path and health, checkpoint activity, guest drivers and updates, recent configuration changes, application health, and virtual NIC. Avoid changing processor count, memory, generation, Secure Boot, or virtual TPM without a specific hypothesis and a recoverable backup.
If several VMs on the same host are affected
Check host CPU and available memory, storage latency and queueing, CSV or SMB/iSCSI/Fibre Channel/MPIO paths, physical NIC and virtual-switch health, host firmware and drivers, antivirus or backup scanning, host patching and reboot history, and cluster events.
If VMs on multiple hosts are affected
Look for shared dependencies: SAN or SMB storage, cluster configuration, network fabric, common backup services, common guest or host updates, and—if the workloads are confidential Azure VMs—Azure platform or confidential-computing factors. Escalate to the responsible infrastructure provider with timestamps and correlated evidence.
Inspect the VM configuration and checkpoints
These read-only checks help establish the VM’s current configuration before changes are considered:
Get-VM -Name 'VM01' | Format-List *
Get-VMMemory -VMName 'VM01'
Get-VMProcessor -VMName 'VM01'
Get-VMHardDiskDrive -VMName 'VM01'
Get-VMNetworkAdapter -VMName 'VM01'
Get-VMIntegrationService -VMName 'VM01'
Get-VMSnapshot -VMName 'VM01'For a specific virtual disk, inspect its metadata:
Get-VHD -Path 'D:VMsVM01Virtual Hard DisksVM01.vhdx' |
Format-List Path, VhdType, FileSize, Size, MinimumSizeLook for a checkpoint being created or merged, a backup job overlapping the incident, a nearly full volume, a deep AVHDX chain, or a merge blocked by locks, permissions, or insufficient space. Heavy storage activity or latency can make a guest appear frozen. Do not manually delete .avhdx files: they may be part of the active virtual-disk chain. Use Hyper-V-aware checkpoint procedures or seek Microsoft or backup-vendor support.
Measure host pressure over time
These counters can provide a starting point, but a single sample is not enough to diagnose an intermittent freeze. Collect them across the incident window and interpret them in the context of the storage type and workload:
Free tools Windows power users keep installed
One-click scans. No signup required.
Get-Counter 'Processor(_Total)% Processor Time',
'MemoryAvailable MBytes',
'LogicalDisk(*)Avg. Disk sec/Read',
'LogicalDisk(*)Avg. Disk sec/Write',
'LogicalDisk(*)Current Disk Queue Length',
'Hyper-V Hypervisor Virtual Processor(*)% Total Run Time',
'Hyper-V Virtual Storage Device(*)Read Latency',
'Hyper-V Virtual Storage Device(*)Write Latency'High disk latency can stall guest I/O; low available memory can cause severe pressure and paging. High host CPU does not, by itself, show that the affected VM is CPU-bound. Counter availability and names can vary by configuration. Compare trends and timestamps with the event logs, rather than drawing conclusions from one reading.
Check network and Integration Services paths
Review physical NIC resets or errors, NIC teaming or Switch Embedded Teaming (SET), virtual-switch events, and driver or firmware compatibility. Check VMQ, SR-IOV, and offload settings when relevant to the configuration and recent changes. If storage uses SMB or iSCSI, investigate that network path too. A management-network outage can prevent VMConnect or remote access while the guest and its applications remain healthy.
Check integration-service status without assuming a legacy manual installation is needed:
Get-VMIntegrationService -VMName 'VM01' |
Select-Object VMName, Name, Enabled, PrimaryStatusDescriptionReview the relevant services, including Heartbeat, Key-Value Pair Exchange, Shutdown, Time Synchronization, VSS, and Guest Service Interface. Modern Windows guests generally receive integration components through the guest OS; the old instruction to mount an Integration Services ISO is not a universal procedure for current guests. Time synchronization problems can affect Kerberos, certificates, and distributed applications, but are not a catch-all explanation for a hard freeze.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Recover in the least disruptive way available
- Try the normal guest access path—RDP, SSH, WinRM, or the application—and compare it with VMConnect.
- If the guest responds, shut it down from within the guest using its normal OS procedure.
- If it does not respond, capture the available host and guest evidence and confirm backup or recovery status before taking a more disruptive action.
- Use Hyper-V’s Turn Off action only when necessary and when the risk of losing in-flight writes is understood. Do not repeatedly reset a VM while storage or checkpoint operations may be active.
- After recovery, verify guest filesystem and application consistency, then inspect for VHDX, NTFS, disk, and application errors.
- If the confidential-VM issue is plausible, verify that the host is on the fixed baseline or a later cumulative update and monitor for recurrence.
When to escalate
If the problem continues after the applicable fix and the host, guest, and dependency checks, Microsoft advises collecting the relevant data and contacting support. Include:
- Host and guest build numbers, installed update history, and VM configuration.
- Exact incident timestamps and whether the VM is confidential.
- Hyper-V VMMS, Worker, Hypervisor, System, storage, network, and clustering logs as applicable.
- Guest logs and dump files, if generated.
- Storage telemetry, backup-job history, checkpoint state, and recent infrastructure changes.
- Whether one VM, one host, or multiple hosts were affected; recovery steps already attempted; and recurrence frequency and business impact.
For an Azure confidential VM, include the Azure VM details and incident timeline in the Azure support case. For symptoms that coincide with storage or backup activity, involve those vendors as well; a platform update cannot resolve every dependency failure.
Quick Recap
Incident checklist
- Confirmed whether the VM is confidential, ordinary Azure, or on-premises.
- Established whether Windows Server 2022 is the host or only the guest.
- Recorded host build and current cumulative-update level.
- Captured incident time, access symptoms, affected VM scope, and recovery state.
- Collected host and guest logs before a forced shutdown where feasible.
- Checked storage latency, network paths, resource pressure, backup overlap, and checkpoints.
- Applied the latest approved applicable update and verified the post-reboot build when warranted.
- Validated guest and application consistency after recovery and monitored for recurrence.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
