Hyper-V Checkpoint Stuck: Diagnose and Remove Orphaned AVHDX Files

Recognizable Condition

When you run Get-VMSnapshot -VMName <VM> and get no results, yet the VM's hard-disk folder contains one or more .avhdx files, the VM is in a checkpoint-stuck state. The VM runs normally, but the disk chain still points to an AVHDX parent that is no longer referenced by a valid checkpoint object. Common symptoms include:

• Long-running backups that never finish, leaving the VM in a Backing up... status.
• Incremental backups that fail after the first run.
• Slow I/O performance that worsens over time.
• Event-log entries in Hyper-V-VMMS about failed checkpoint merges.

Underlying Cause

Since Windows Server 2016, Hyper-V uses production checkpoints by default. A production checkpoint creates a .avhdx differencing disk and freezes the parent .vhdx. If the backup process aborts (for example, a VSS writer failure, a full host disk, or an integration services mismatch), the checkpoint object can be removed while the .avhdx remains. The VM's disk chain still references the orphaned AVHDX, but PowerShell no longer lists a snapshot, making the problem invisible to most users.

Because checkpoints are not backups, they should be merged or deleted as soon as they are no longer needed. Leaving orphaned AVHDX files can:

• Consume disk space indefinitely.
• Introduce I/O latency.
• Cause merge failures that block further backups.

Diagnostic Table

Condition	Likely Cause
VM shows Backing up... but no snapshots.	Orphaned checkpoint from a failed backup.
AVHDX file present, Get-VMSnapshot returns nothing.	Merge pending or broken chain.
Event Viewer: VSS errors in guest log.	Integration services or VSS writer failure.
Checkpoint creation fails.	Insufficient host disk space or permissions.

Ordered Checks

1. List snapshots
   Run on the Hyper-V host in an elevated PowerShell session:

   Get-VMSnapshot -VMName <VM>

   Check whether any snapshot objects exist.
2. Inspect the disk chain
   Locate the VM's disk path with Get-VMHardDiskDrive -VMName <VM>, then run:

   Get-VHD -Path <DiskPath> | Format-List

   A non-empty ParentPath pointing to an AVHDX indicates a differencing chain is still active.
3. Check event logs
   Open Event Viewer and navigate to:
   • Applications and Services Logs > Microsoft > Windows > Hyper-V-VMMS
   • Guest OS: Application log for VSS writer errors.
   Search for checkpoint- or VSS-related errors that match the timeline of the failed backup.
4. Verify integration services
   On the host, run:

   Get-VMIntegrationService -VMName <VM> | Format-List Name, Enabled, PrimaryStatusDescription

   Ensure the VSS integration service is enabled and healthy, and that integration services in the guest are current for the host's Hyper-V version.
5. Check host disk space
   Confirm the volume holding the VM's disks has enough free space for a merge. A nearly full volume can block checkpoint merges and new checkpoint creation.

Fixes Tied to Findings

• No snapshots but AVHDX present
  Create a new standard checkpoint to trigger a merge, then delete it:

  Checkpoint-VM -VMName <VM> -SnapshotName "TempMerge"
  Remove-VMSnapshot -VMName <VM> -Name "TempMerge"

  If merging fails, export the VM, remove the orphaned files, and re-import.
• Broken chain (ParentPath points to a missing file)
  Use Hyper-V Manager's Inspect Disk action: select the disk, choose Reconnect, and point it at the correct parent. After reconnection, delete the checkpoint so the merge can run. Merges typically require the VM to be powered off to complete.
• VSS writer failures
  Update integration services in the guest, then restart the Hyper-V Volume Shadow Copy Requestor service on the host. Verify writer health inside the guest with:

  vssadmin list writers

  All writers should report a stable state with no errors.
• Insufficient disk space
  Free space on the host volume or move the VM storage to a larger volume, then retry the merge.

Escalation Criteria

1. Merge fails repeatedly with disk-in-use or file-not-found errors.
2. The AVHDX chain is corrupted (for example, a missing parent) and cannot be reconnected.
3. The host volume is critically low on space and cannot be expanded to complete a merge.
4. The VM hosts a production service and the available downtime window has been exhausted.

When any of these occur, plan a restore from a clean backup or engage Microsoft support for advanced recovery.

Limitations and Practical Checks

• Do not delete AVHDX files manually from the file system while the VM references them; this breaks the differencing chain and can render the VM unbootable.
• Checkpoint merges require free disk space and usually require the VM to be powered off; plan a maintenance window.
• The behavior described applies to Windows Server 2016-2022 and Windows 10/11 client Hyper-V. Cmdlet behavior and checkpoint defaults are version-sensitive, so confirm against your host version before scripting fixes.
• After a fix, verify by booting the VM, confirming Get-VMSnapshot returns nothing, and confirming no AVHDX files remain in the disk folder.
• Run Get-VHD on the parent disk to confirm ParentPath is empty after the merge.

Practical Verification Example

Assume VM SQLServer01 has an orphaned AVHDX. A typical cleanup sequence on the host (elevated PowerShell) is:

1. Get-VMSnapshot -VMName SQLServer01 returns nothing, but Get-VMHardDiskDrive shows the VM attached to an .avhdx file.
2. Get-VHD -Path <DiskPath> | Format-List shows a ParentPath pointing to the base VHDX, confirming the differencing chain.
3. Run Checkpoint-VM -VMName SQLServer01 -SnapshotName TempMerge, then Remove-VMSnapshot -VMName SQLServer01 -Name TempMerge to force the merge.
4. Verify Get-VMSnapshot still returns nothing and the AVHDX file is gone from the disk folder.

After these steps, the VM's disk chain is clean and normal backup operations can resume. Test this procedure on a non-production VM first to confirm the behavior on your host version.