How to Merge Hyper-V AVHDX Checkpoint Files

You open a VM’s folder expecting one tidy VHDX and instead find a pile of AVHDX files with long GUID names, some of them gigabytes in size. The backup ran last night, or a checkpoint operation hiccuped, and now the chain never collapsed back down. The VM still runs, but it’s running off a differencing disk it was never meant to keep.

This is recoverable, and your data is almost certainly fine. But how you clean it up matters a lot: delete the wrong file and you’ll break the chain and lose everything written since that point. This guide explains what AVHDX files are, why they get orphaned, and the two safe ways to merge them back into the base disk.

What an AVHDX actually is#

An AVHDX is a differencing disk — a child of another virtual disk. When you take a checkpoint, Hyper-V doesn’t copy the disk. It marks the current VHDX read-only and creates an AVHDX next to it. From then on, every write goes into the AVHDX while the parent sits frozen. Stack more checkpoints and you get a chain, each AVHDX pointing back to the one before it:

disk.vhdx  →  disk_AC1F....avhdx  →  disk_9B22....avhdx  (active — VM writes here)
   base           child 1                child 2

The key facts that make merging safe or dangerous:

• The base VHDX holds the old data, frozen at the moment of the first checkpoint.
• Each AVHDX holds only the changes since its parent.
• The newest AVHDX is live — the VM is writing to it right now.
• A child is useless without its parent. The full chain together is your current disk state.

So an AVHDX isn’t junk to be cleared out. It’s the only place a chunk of your data lives. Merging folds those changes back into the parent; deleting throws them away.

Why they get orphaned#

Under normal use you never see this. You take a checkpoint, you delete it, Hyper-V merges the AVHDX back into the parent, and the file disappears. Orphaned AVHDX files show up when that delete-and- merge step never finishes.

The usual cause is a backup job. Most Hyper-V backup tools work like this: create a checkpoint, so the base VHDX goes read-only and can be copied safely; copy the now-frozen base; then merge the AVHDX and remove the checkpoint. If the backup process crashes, times out, loses its VSS session, or the host reboots mid-job, you’re left at the merge step that never ran. The AVHDX stays on disk, the VM keeps writing to it, and the checkpoint may or may not still appear in Hyper-V Manager.

A failed manual checkpoint can leave the same mess — which is why this and fixing a failed Hyper-V checkpoint so often go together.

Before you touch anything: check the chain and back up#

Two things first, every time. Confirm the chain, and protect yourself.

# Inspect the active disk and walk up its parents
Get-VHD -Path "C:\VMs\MyVM\disk_9B22.avhdx" | Select-Object Path, ParentPath, VhdType, @{N="SizeGB";E={[math]::Round($_.FileSize/1GB,2)}}

Follow each ParentPath up to the base VHDX and confirm every file exists at the path listed. If a parent is missing or moved, fix that first — a merge across a broken link will fail.

Also make sure the host volume has enough free space. Merging writes the child’s data into the parent, and during the operation both need to coexist — budget roughly the size of the AVHDX chain in free space.

Method 1: Recreate the checkpoint, then delete it (preferred)#

This is the safest approach and it can run while the VM is on. The idea is to get the orphaned AVHDX recognized as a proper checkpoint again, then let Hyper-V do the merge it was supposed to do.

If the checkpoint still shows in Hyper-V Manager:

1. Open Hyper-V Manager and select the VM.
2. In the Checkpoints pane, right-click the checkpoint and choose Delete Checkpoint (or Delete Checkpoint Subtree if there are several).
3. Watch the VM’s status — it will show a Merge in progress state. Let it finish completely.

In PowerShell, deleting the checkpoint object triggers the same live merge:

# List checkpoints for the VM
Get-VMSnapshot -VMName "MyVM"

# Delete one (merges its AVHDX into the parent)
Remove-VMSnapshot -VMName "MyVM" -Name "Backup - 2026-07-12"

# Or remove the whole tree
Get-VMSnapshot -VMName "MyVM" | Remove-VMSnapshot

After the merge completes, the AVHDX files disappear and the VM points back at a single VHDX. Confirm with Get-VMHardDiskDrive -VMName "MyVM" — the Path should end in .vhdx, not .avhdx.

If the checkpoint no longer appears in Hyper-V Manager but the AVHDX is still on disk and still attached, the cleanest move is often to take a brand-new checkpoint and immediately delete it. That forces Hyper-V to walk and consolidate the chain, sweeping up the orphaned differencing disk in the process. If the VM won’t even start because of the broken chain, go to Method 2.

Method 2: Shut down and merge with Edit Disk or Merge-VHD#

Use this when the checkpoint is gone from Hyper-V Manager, when a live merge won’t run, or when the VM is offline anyway. The non-negotiable requirement: the VM must be shut down. The active AVHDX is locked while the VM runs, and merging a disk that’s in use corrupts it.

Using Edit Disk (GUI)#

1. Shut the VM down.
2. In Hyper-V Manager, click Edit Disk in the Actions pane.
3. Browse to the newest AVHDX in the chain and select it.
4. Choose Merge.
5. Choose To the parent virtual hard disk to fold it into its immediate parent.
6. Repeat for each remaining AVHDX, working from newest down to the base.

Using PowerShell (Merge-VHD)#

Merge-VHD can collapse the whole chain in one command by merging a child into a destination ancestor, as long as every link resolves:

# Merge the active AVHDX all the way down into the base VHDX
Merge-VHD -Path "C:\VMs\MyVM\disk_9B22.avhdx" -DestinationPath "C:\VMs\MyVM\disk.vhdx"

If you’d rather go one link at a time, omit -DestinationPath to merge a child into its direct parent:

Merge-VHD -Path "C:\VMs\MyVM\disk_9B22.avhdx"

Reattach after a manual merge#

After a Method 2 merge, the VM’s configuration may still point at the now-merged-away AVHDX. Point it back at the base VHDX:

Set-VMHardDiskDrive -VMName "MyVM" -ControllerType SCSI -ControllerNumber 0 -ControllerLocation 0 -Path "C:\VMs\MyVM\disk.vhdx"

Adjust the controller type and numbers to match the VM. Then start the VM and confirm it boots and the data is current.

Quick recovery checklist#

Wrapping up#

Orphaned AVHDX files look alarming but they’re a routine cleanup once you understand the chain. The data is intact; it’s just spread across a parent and one or more children that never got consolidated. Whenever you can, let Hyper-V do the work — recreate or delete the checkpoint and let the live merge run. Fall back to a shutdown plus Edit Disk or Merge-VHD only when the checkpoint object is gone or the VM won’t start. And never, ever delete an AVHDX by hand.

The deeper lesson is the same one that bites people with VMware snapshots, which are not backups: differencing disks are a temporary mechanism, not storage you keep. Watch your backup jobs for failed merges, keep an eye on VM folders, and consolidate promptly. If your checkpoints are failing in the first place, fix that at the source — see how to fix a failed Hyper-V checkpoint.