Diagnosing Hyper-V Checkpoints That Won't Merge: Orphaned AVHDX Disks

The condition you'll recognize

You delete a checkpoint in Hyper-V Manager, expect the .avhdx differencing disk to merge back into its parent, and instead the VM sits in \"Merge in progress\" or \"Checkpoint\" state indefinitely. Hours later the .avhdx files are still on the volume, backups start failing, and live migration refuses to run because the disk chain is in an intermediate state.

The useful takeaway: a stuck merge is almost never random. It comes down to one of a handful of causes — free space, a backup product holding the checkpoint open, storage errors, or an interrupted previous merge — and each cause has a distinct fix. Working through the checks below in order prevents the two mistakes that turn this from an annoyance into data loss: deleting .avhdx files by hand, or merging the wrong disk pair.

Applies to Windows Server 2016, 2019, and 2022 Hyper-V hosts. Checkpoint defaults and merge behavior differ slightly between versions, so confirm your host version with winver before following any procedure.

Cause and diagnostic quick reference

Ordered checks before touching anything

Run these from an elevated PowerShell session on the Hyper-V host (local administrator or equivalent). Replace VMNAME and paths with your values.

1. Confirm the disk chain is intact

Get-VMHardDiskDrive -VMName VMNAME\nGet-VHD \"D:\\VMs\\VMNAME\\disk_1.avhdx\"

Get-VHD shows the ParentPath of each differencing disk. Walk the chain from the youngest .avhdx down to the base .vhdx. Every parent path must exist and point where you expect. If the chain is broken or re-pointed, stop — the fix is entirely different and manual merging is dangerous here.

2. Check free space

A merge writes consolidated data, so the volume needs enough headroom. Compare free space against the combined size of the .avhdx files. If space is the constraint, free it up before retrying — do not attempt a merge on a nearly full CSV or local volume.

3. Read the event logs

In Event Viewer, open Applications and Services Logs → Microsoft → Windows → Hyper-V-VMMS and Hyper-V-Worker. Look for merge failures, storage errors, or events timestamped around a host reboot or VMMS restart — that pattern indicates an interrupted merge.

4. Check for a backup product's checkpoint

Get-VMCheckpoint -VMName VMNAME

A recovery checkpoint created by backup software (often named by the vendor) can block deletion and merging. If one exists, coordinate with the backup job — let it finish or remove the checkpoint through the backup product's own mechanism where supported.

Fixes tied to findings

Standard path: remove checkpoints and power off fully

1. Shut the VM down cleanly — a full power off, not saved state. Merges only complete when the VM is fully off.
2. Remove lingering checkpoints: Get-VMCheckpoint -VMName VMNAME | Remove-VMCheckpoint, or via Hyper-V Manager.
3. Watch the VM status; the merge should trigger and complete while the VM is off.

Fallback: controlled manual merge

Only if the automatic merge never triggers, and only after a verified backup and full shutdown:

1. Verify the chain again with Get-VHD — confirm the exact child and parent pair.
2. Merge the youngest .avhdx into its parent: Merge-VHD -Path \"D:\\VMs\\VMNAME\\disk_1.avhdx\". Merge one level at a time, youngest first.
3. Re-point the VM's disk to the merged parent via Hyper-V Manager settings, then start the VM and verify data.

Merging the wrong pair or in the wrong order can corrupt data. Never delete .avhdx files from the file system while the VM references them, and never edit or expand a parent disk while children exist.

Escalate instead of forcing it when

• Event logs show storage or CSV corruption rather than a simple merge failure.
• The chain is broken — a parent disk is missing or paths don't resolve.
• The VM holds business-critical data with no current verified backup.
• Repeated merges fail after space and backup-interference causes are ruled out.

In those cases, engage Microsoft support or a storage specialist rather than experimenting on production data.

Verifying the result

After remediation: power the VM fully off, confirm the .avhdx files disappear from the volume, confirm Get-VMHardDiskDrive shows only the parent .vhdx, then take a test backup to prove the chain is healthy end to end.