How to Fix Hyper-V Checkpoint Failed

You right-click a VM, choose Checkpoint, and instead of a quick snapshot you get a red error box: “Could not create checkpoint for virtual machine.” Sometimes it’s a VSS complaint, sometimes a file-not-found, sometimes nothing useful at all. The operation that’s supposed to give you a safe rollback point before patching just refused to run.

Checkpoint failures almost always trace back to one of a few things: the volume is out of space, the VM lost permission to its own disk files, the guest’s VSS layer is broken, or the AVHDX chain is in a state Hyper-V won’t touch. The trick is knowing which one you’re looking at. This guide covers what a checkpoint actually does, then walks the causes in the order that finds the fault fastest.

What a checkpoint really creates#

When Hyper-V takes a checkpoint, it doesn’t copy the whole disk. It freezes the current VHDX as read-only and creates a new AVHDX differencing disk beside it. From that moment, every write the VM makes lands in the AVHDX while the original VHDX stays untouched. Take a second checkpoint and you get another AVHDX on top, forming a chain:

base.vhdx  →  base_GUID1.avhdx  →  base_GUID2.avhdx  (active, VM writes here)

That chain matters for troubleshooting. If any link is missing, locked, or unwritable, the checkpoint operation fails — and so does deleting one, which is its own headache. Understanding the chain is also what makes merging orphaned AVHDX files safe later on.

Standard vs production checkpoints#

Since Windows Server 2016 and Windows 10, the default is a production checkpoint, and that default is behind a lot of failures people don’t expect.

The important part: a production checkpoint depends on the guest’s VSS being healthy. A standard checkpoint doesn’t. So if your checkpoints fail with VSS errors but you don’t strictly need application consistency, switching the VM to standard checkpoints — or allowing fallback — often makes the error disappear.

# See the current checkpoint type
Get-VM "MyVM" | Select-Object Name, CheckpointType

# Allow Hyper-V to fall back to a standard checkpoint if production fails
Set-VM "MyVM" -CheckpointType ProductionOnly   # strict production, no fallback
Set-VM "MyVM" -CheckpointType Production        # production, falls back to standard
Set-VM "MyVM" -CheckpointType Standard          # always standard

Production (with fallback) is the most forgiving setting. ProductionOnly will hard-fail if VSS can’t deliver, which is correct for backup-critical workloads but frustrating on a lab VM.

Cause 1: The volume is out of space#

This is the most common and the easiest to miss. A checkpoint needs room for the new AVHDX on the host volume that holds the VHDX, and a production checkpoint also needs free space inside the guest for VSS to stage its shadow copy. Either being tight will fail the operation.

Check the host side first:

Get-Volume | Format-Table DriveLetter, FileSystemLabel, @{N="FreeGB";E={[math]::Round($_.SizeRemaining/1GB,1)}}, @{N="SizeGB";E={[math]::Round($_.Size/1GB,1)}}

Then check free space inside the VM. VSS typically wants a meaningful chunk free on each volume it snapshots — a guest sitting at 99% full is a classic cause of a failed production checkpoint that works fine the moment you clear a few gigabytes.

Cause 2: The VM lost permission to its disk files#

Every Hyper-V VM runs under a unique virtual account, and that account’s SID (NT VIRTUAL MACHINE\<VM-GUID>) needs Full Control on the VHDX/AVHDX files and the folder they live in. Copy or move those files in Explorer, restore them from a backup, or drop them on a new volume, and those ACLs usually don’t come along. Hyper-V then can’t create the AVHDX, so the checkpoint fails — often with an access-denied or generic failure message.

The clean repair is to re-point the disk through Hyper-V, which re-applies the correct ACL:

# Re-attaching the disk via Hyper-V re-grants the per-VM permission
$vm = "MyVM"
$disk = (Get-VMHardDiskDrive -VMName $vm)
Set-VMHardDiskDrive -VMName $vm -ControllerType $disk.ControllerType -ControllerNumber $disk.ControllerNumber -ControllerLocation $disk.ControllerLocation -Path $disk.Path

If you’d rather set it directly, grant the VM’s GUID account Full Control on the VHDX file and its parent folder with icacls, using the GUID shown by (Get-VM "MyVM").VMId.

Cause 3: VSS is broken inside the guest#

For production checkpoints, the guest does the heavy lifting through the Volume Shadow Copy Service. If a VSS writer is wedged, the checkpoint can’t get a consistent snapshot and Hyper-V reports failure. Start by listing the writers inside the VM:

vssadmin list writers

Look for any writer in a state other than Stable with a No error last-error value. A writer stuck in Failed, Timed out, or Retryable error is your culprit. The usual reset is to restart the relevant service or the VSS service itself, then retry:

# Inside the guest
Restart-Service VSS
# If a specific writer is hosted by another service (e.g. SQL), restart that service too

Two related checks while you’re in the guest:

• Integration services. The Backup (volume checkpoint) integration service must be enabled for the VM. Confirm with Get-VMIntegrationService -VMName "MyVM" on the host and make sure VSS / Backup shows enabled and the guest’s Hyper-V Integration services are running.
• Linux guests. There’s no VSS. Production checkpoints rely on the hv_vss_daemon from the Linux Integration Services. If that daemon isn’t running, the production checkpoint can’t freeze the filesystem and falls back or fails depending on your checkpoint type.

Cause 4: A broken AVHDX chain#

If the error mentions a file that can’t be found, or you’ve recently moved disks around, the differencing chain is probably broken. A child AVHDX stores the path to its parent; rename or relocate that parent and the link snaps. Hyper-V won’t create a new checkpoint on top of a chain it can’t fully resolve.

Follow the chain and confirm every parent exists:

# Walk the chain for the VM's disk
Get-VHD -Path "C:\VMs\MyVM\base_GUID2.avhdx" | Select-Object Path, ParentPath, VhdType

Keep following ParentPath up to the base VHDX. If a parent path points somewhere the file no longer is, restore it to that exact location or repair the reference. Once the chain resolves end to end, checkpoints work again — and if you’re left with stray AVHDX files after a failed backup, the safe way to consolidate them is covered in merging Hyper-V AVHDX checkpoint files.

Cause 5: Checkpoints are disabled or blocked#

Worth a quick look before you go deeper. Checkpoints can simply be turned off for a VM, and some configurations block them outright.

Get-VM "MyVM" | Select-Object Name, CheckpointType, @{N="Enabled";E={$_.AutomaticCheckpointsEnabled}}

A few situations where Hyper-V won’t checkpoint at all: a VM with a physical (pass-through) disk attached, a VM using a shared VHD Set in some configurations, or checkpoints disabled in the VM’s settings. If the VM uses pass-through storage, that’s by design — Hyper-V can’t snapshot a disk it doesn’t own.

The fast path#

When a checkpoint fails and you want it working:

Most failures land on space or VSS. Permissions and broken chains show up right after someone moves disk files. Disabled checkpoints and pass-through disks explain the rest.

A word on what checkpoints are for#

Checkpoints are a short-term safety net — take one before a risky patch or config change, then delete it once you’re confident. They are not backups. They sit on the same storage as the VM, the AVHDX chain grows the longer you keep them, and a stack of forgotten checkpoints will quietly fill a volume and eventually cause the very failures above. The same logic that applies to VMware applies here: snapshots are not backups. Keep a real backup, and delete checkpoints promptly so the AVHDX files merge back down.

Wrapping up#

A failed Hyper-V checkpoint is rarely random. Start with the event logs to get a real reason, then check the obvious physical causes — host and guest free space — before moving to VSS health and integration services for production checkpoints. If you’ve been moving virtual disks, suspect lost permissions or a broken AVHDX chain. And if a particular VM doesn’t need application consistency, switching it to standard or fallback checkpoints sidesteps the entire VSS dependency.

Above all, don’t let checkpoints accumulate. The cleaner you keep the chain, the fewer of these errors you’ll ever see.