Hyper-V VM Will Not Start: Broken AVHDX Checkpoints

When a Hyper-V virtual machine has checkpoints, its disk is not a single file. The original virtual hard disk (VHDX) becomes a read-only parent, and every change since the checkpoint is written to a child file with the .avhdx extension. The running VM uses the whole chain. That design works well until something changes one of the files without Hyper-V knowing about it, at which point the chain no longer matches and the VM will not start.

The most common are an interrupted checkpoint merge, for example from a power loss or a full volume while the merge was running, and files that were moved, renamed, resized or deleted by hand. Storage running out of space is another frequent cause, because the .avhdx files grow as the VM runs, and a volume that fills up can pause the VM and leave the chain in a bad state. Restoring only some of the files from a backup produces the same result.

Copy the whole VM folder, including all VHDX and AVHDX files, the configuration files, and any snapshot folders, to separate storage. If the disks are on a failing volume, take an image of the volume instead. Treat the originals as read-only from this point. Most repair steps for a broken chain modify files, and a copy is what keeps the other options available.

The PowerShell command Get-VHD shows a disk's parent path and identifiers, and Test-VHD checks a disk for consistency. Together they show which link in the chain is missing, moved or mismatched. A parent that has genuinely been changed since the child was created is a much more serious problem than a parent that has only been moved to a different folder.

If the parent file is unchanged and only its location or identifier no longer matches, Hyper-V provides ways to re-point the child disk to the right parent, including an option to ignore an identifier mismatch. That is only safe when the parent really has not been modified. If it has, the option produces a disk that mounts but whose contents are inconsistent, and the problem may not show up until later.

Do not merge the disks, expand them, or delete checkpoint files by hand as a way of tidying up. A merge is irreversible, and if the chain is wrong, it merges the wrong data. Also avoid attaching the parent disk to a running VM and writing to it, because that changes the parent and invalidates every child that depends on it.

If the chain has a missing link, if the parent has been modified, or if the VM's data matters and a merge has already run, the way forward depends on what is left in the files. Data can often be extracted from a broken chain by reading the disk files directly, and we have done it in many cases. Keep the originals untouched and work from the copy.