Hyper-V Checkpoint Operation Failed: A Read-First VSS, Storage, Permissions, and Orphaned AVHDX Triage

Helpdesk: "The nightly backup for APP02 failed again: 'Failed to create VM recovery checkpoint ... error code: 32768'. I tried a manual checkpoint in Hyper-V Manager and got 'Checkpoint operation failed' and 'APP02 could not initiate a checkpoint operation.' The V: drive on HV01 is at 96%, and the VM folder is full of .avhdx files. Someone on the team says just delete the old .avhdx files to free space and try again. Can you do that?"

Don't delete anything yet. "Checkpoint operation failed" in Hyper-V is a wrapper message, and the fix depends on which layer underneath it actually failed. Deleting .avhdx files by hand is how a failed backup turns into a VM that won't start. It's one layer in a documented chain: the exact message, hex code, and operation (create, apply, delete, merge) on the ticket → the VM's checkpoint settings allow the checkpoint you asked for (type, enabled, file location, supported disks) → the guest's VSS path works (the Backup / VSS integration service, the Hyper-V Volume Shadow Copy Requestor, guest VSS writers) → the host's VSS path works (the Hyper-V VSS writer, no overlapping backup jobs) → the volume has room for new differencing disks and for merges → permissions and antivirus aren't blocking the VM's files → the existing checkpoint chain is healthy (no orphaned, hidden, or broken .avhdx files) → the Hyper-V VMMS event log shows what failed and when. Get-VM, Get-VMSnapshot, Get-VMIntegrationService, Get-VMHardDiskDrive, Get-VHD, Test-VHD, vssadmin list writers, Get-Volume, icacls, and Get-WinEvent are the sources for that chain. A quick fix can make the error go away. If the real problem was a stuck guest VSS writer or a hidden backup checkpoint, the next backup fails the same way.

If a checkpoint was already applied to a domain member and it now refuses domain sign-ins, start with Trust Relationship Between This Workstation and the Primary Domain Failed. If the real question is what you can restore when this goes wrong, read Retention Is Not Backup for the restore-drill habit. This post covers "a Hyper-V VM returns 'Checkpoint operation failed' (manually or from a backup job), or its checkpoints won't delete or merge, and you need a read-first path through the checkpoint settings, guest and host VSS, storage, permissions, the .avhdx chain, and the event logs before you delete files, restart services, change checkpoint types, or merge disks."

TL;DR

• Read the inner error, not the headline. "Checkpoint operation failed" is the wrapper. The line under it (could not initiate a checkpoint operation, a hex code like 0x80070020, Production checkpoints cannot be created) tells you which layer to read.
• Production checkpoints depend on VSS inside the guest. Microsoft: production checkpoints use Volume Shadow Copy Service (or File System Freeze on Linux). With -CheckpointType Production, Hyper-V falls back to a standard checkpoint if that fails. With ProductionOnly, the operation fails instead.
• Never delete .avhdx files directly. Microsoft: "You should not delete the .avhdx files directly." Deleting a checkpoint merges its .avhdx into the parent. Shutting the VM down usually triggers the merge for checkpoints you can't see.
• Merges need space. Microsoft's checklist says to make sure there's enough free space for merges, "ideally, space equal to the disk size."
• Backup tools leave checkpoints behind. Microsoft's merge article: checkpoints that don't appear in Hyper-V Manager are often from "third-party backup software" that "doesn't clean them up."
• Some disks can't be checkpointed at all. Pass-through disks, shared VHDX, and virtual Fibre Channel aren't supported, according to Microsoft's troubleshooting guide.

---

Where in the chain did it break?

Step	What should be true	Typical symptom when it breaks
1. Symptom captured	Exact message and hex code, which operation, manual or backup job, checkpoint type, VM state, when it started	"Checkpoints are broken" with no VM, operation, or error text
2. Checkpoint settings	Checkpoints enabled, type is what you expect, file location valid, no unsupported disks	Fails instantly on one VM; works on others on the same host
3. Guest VSS	VSS integration service enabled and OK; Hyper-V Volume Shadow Copy Requestor running; guest writers stable	Production checkpoints cannot be created; backup job fails at the checkpoint step
4. Host VSS	Hyper-V VSS writer stable; one backup job per VM at a time	Every VM on the host fails a backup at the same time
5. Storage	Room for new .avhdx files and for merges; CSV healthy	Volume near full, could not create auto virtual hard disk
6. Permissions and AV	VM accounts can write the folder; AV excludes Hyper-V files and processes	Access denied, or 0x80070020 (file in use)
7. Existing chain	No orphaned, hidden, or broken differencing disks	.avhdx files the Manager doesn't show, 0x80070032, delete greyed out
8. Event logs	VMMS and worker events read for the failure time	No idea which step failed or which process held the file
9. Change	Only after Steps 1-8 agree: one layer, one change	Services restarted, files deleted, still failing tomorrow

---

Step 1: Capture the exact error (read-only)

Hyper-V usually returns a stack of lines. The first one is generic, and the useful one is underneath. Microsoft's backup troubleshooting article lists messages backup tools show, such as Failed to create VM recovery checkpoint ... error code: 32768 and Could not create backup checkpoint for virtual machine - Error -0x800423F2, and file-lock errors such as The process cannot access the file because it is being used by another process. (0x80070020). Write these on the ticket before anyone changes anything:

Fact	Why it matters
Every line of the error, with hex codes	0x80070020 (file in use), 0x80070032 (chain), access denied, or "directory or file cannot be created" each point at a different step
Which operation	Create, apply, delete, and merge fail for different reasons. A failed delete is usually a merge problem (Step 7)
Manual or backup job?	A backup job's "recovery checkpoint" failing while a manual standard checkpoint works points at VSS (Steps 3-4)
Checkpoint type on the VM	Production can fall back to standard. ProductionOnly fails instead (Step 2)
VM state	Microsoft's checklist: verify the VM isn't "saved," "creating checkpoint," or "stopping"
One VM or every VM on the host?	One VM: settings, guest VSS, or its files. Every VM: host VSS, storage, AV, or the backup tool
What changed?	New backup product or job, AV update, storage move, host patching, a VM migrated from another host

Then match the symptom:

What you see	Likely layer
Production checkpoints cannot be created	Guest VSS or the checkpoint type (Steps 2-3)
Backup tool: Failed to create VM recovery checkpoint ... 32768	Guest or host VSS, or a leftover backup checkpoint (Steps 3, 4, 7)
Fails instantly; nothing in the VM folder changes	Checkpoints disabled, unsupported disk type, or invalid file location (Step 2)
could not create auto virtual hard disk ... cannot be created	Storage, permissions, or the file location (Steps 2, 5, 6)
Access denied	Permissions (Step 6)
0x80070020 (file in use)	Backup, AV, or another process holds the file (Step 6)
0x80070032 or a broken chain	Chain corruption (Step 7)
Delete Checkpoint greyed out or missing	A backup-created checkpoint (Step 7)
.avhdx files on disk that Hyper-V Manager doesn't show	Orphaned differencing disks (Step 7)
VM stuck at "creating checkpoint"	Stuck host task (Step 8)
Every VM on the host fails at once	Host VSS, storage, or the backup tool (Steps 4-5)

---

Step 2: Read the VM's checkpoint settings (read-only)

Microsoft documents four values for Set-VM -CheckpointType:

CheckpointType	What Microsoft says it does	Why it matters for this ticket
Disabled	"Block creation of checkpoints"	Every checkpoint fails, including the backup tool's
Standard	Create standard checkpoints	Memory state is captured; no VSS in the guest
Production	Production checkpoints "if supported by guest operating system. Otherwise, create standard checkpoints"	A VSS problem can hide behind a quiet fallback to standard
ProductionOnly	Production checkpoints if supported, "Otherwise, the operation fails"	VSS problems surface as a hard failure

# Read-only. Hyper-V module, elevated on the host: state, heartbeat status, checkpoint settings
Get-VM -Name 'APP02' |
  Format-List Name, State, Status, CheckpointType, SnapshotFileLocation, Path

State and Status come from Microsoft's integration services page (the Status field is set by the heartbeat service). The CheckpointType and SnapshotFileLocation property names match the Set-VM parameters (our reading). If they come back empty on your version, run Get-VM -Name 'APP02' | Format-List *.

# Read-only. Disks attached to the VM, and whether any are passed through rather than a VHD file
Get-VMHardDiskDrive -VMName 'APP02' |
  Format-Table ControllerType, ControllerNumber, ControllerLocation, Path, DiskNumber -AutoSize

A disk with a DiskNumber and no .vhdx Path is a pass-through disk (our reading of the output). Microsoft's guide lists pass-through disks, shared VHDX, and synthetic Fibre Channel as unsupported for checkpoints: "Remove or convert pass-through or shared disks to .vhdx or use a third-party backup for these workloads."

What else to read in the settings:

Setting	What Microsoft says	What to check
Enable Checkpoints	Selected by default; clearing it disables checkpoints	Someone cleared it to stop "snapshot sprawl"
Checkpoint File Location	Can only be changed "if the virtual machine has no checkpoints"	The folder still exists after a storage move, and the VM can write to it
Default location	%SystemDrive%\ProgramData\Microsoft\Windows\Hyper-V\Snapshots (per Microsoft's antivirus exclusion list)	A VM still pointing at the system drive fills C: on the host
Older VSS backup reference	For the online "Child VM Snapshot" backup method, the Snapshot File Location should be on the same host volume as the VM's VHD files	A checkpoint location on a different volume (our reading: worth checking on any VM whose backups keep falling back to saved state)

---

Step 3: Guest VSS and integration services (read-only)

Production checkpoints and online backups go through VSS inside the guest. Microsoft's integration services reference: the Hyper-V Volume Shadow Copy Requestor (Windows service vmicvss, Linux daemon hv_vss_daemon) "allows Volume Shadow Copy Service to back up applications and data on the virtual machine." When it's disabled, "the virtual machine can't be backed up while running (using VSS)."

# Read-only. On the host: is the VSS integration service enabled and healthy for this VM?
Get-VMIntegrationService -VMName 'APP02' |
  Format-Table Name, Enabled, PrimaryStatusDescription, SecondaryStatusDescription -AutoSize

Microsoft's sample output shows every line as OK, including VSS. Two rules from Microsoft's "Manage Hyper-V integration services" page matter here:

• "Each service you want to use must be enabled in both the host and guest in order to function."
• "If you disable the service in the guest, Hyper-V is unable to start it." A guest-side GPO or hardening script that disables vmicvss breaks production checkpoints with no change on the host.

Any status other than OK on the VSS line (we often see "Lost Communication" or "No Contact", our field reading) means read the guest next:

# Read-only. INSIDE the guest (console, RDP, or Enter-PSSession): integration services and VSS
Get-Service -Name vmic* | Format-Table Status, Name, DisplayName -AutoSize
Get-Service -Name VSS, swprv | Format-Table Status, StartType, Name, DisplayName -AutoSize

# Read-only. INSIDE the guest, elevated: VSS writers and their state
vssadmin list writers

Microsoft's examples of vssadmin list writers output show states like [1] Stable and [9] Failed, with a Last error line for each writer. A failed application writer inside the guest (SQL Server, Exchange, a third-party agent) is a common reason a production checkpoint fails while a standard one works (our reading). Microsoft's backup article also lists Event ID 12293 in the guest and Event ID 8229 on the host as VSS writer errors to look for.

Also from Microsoft's older Hyper-V VSS backup reference, the online "Child VM Snapshot" method needs: the Hyper-V Volume Shadow Copy Requestor installed and running, the VM running, basic disks only (no dynamic disks), and a file system that supports snapshots (for example, NTFS). If those aren't met, Hyper-V backs the VM up with the "Saved State" method instead. That page predates production checkpoints, so treat it as background for backup jobs, not a checkpoint rule (our reading).

On Hyper-V hosts earlier than Windows Server 2016 and Windows 10, Microsoft says you install or update integration services in the guest by hand. On newer hosts, Windows guests get them through Windows Update. A guest that never patches can end up with out-of-date components. Microsoft's Get-VMIntegrationService example filters on SecondaryOperationalStatus -eq 'ProtocolMismatch' for exactly that.

---

Step 4: Host VSS and the backup tool (read-only)

Microsoft: the Hyper-V VSS writer is "part of the 'Hyper-V Virtual Machine Management' service" on the host. And: "Partial backups are not supported. If any virtual machine fails to create a snapshot, no virtual machines will be backed up." That's why one bad VM can fail a whole multi-VM backup job.

# Read-only. On the host, elevated: is the Hyper-V VSS writer stable?
vssadmin list writers

Look for the Hyper-V writer (Microsoft's VSS article calls it the "Microsoft Hyper-V VSS writer") and its State and Last error. Microsoft's backup article lists causes for writer failures and timeouts as "often due to overlapping backup jobs or VSS operations," and the fix as staggering backup schedules.

What to read before you blame the host:

Question	Where to look	Why
Did the last backup finish and clean up?	The backup tool's job history	Microsoft's checklist: verify "backup applications report merging or cleanup of their checkpoints"
Do two jobs overlap?	Backup schedules, replication jobs, host-level and in-guest agents	Overlapping VSS operations are a documented cause
Does a manual checkpoint fail too?	Hyper-V Manager or Step 9's Checkpoint-VM -WhatIf first	If manual works and the backup fails, the backup tool's settings come first
Is it every VM?	The same error across VMs on HV01	Points at the host writer, storage, or AV

---

Step 5: Room for checkpoints and merges (read-only)

Every new checkpoint creates differencing disks, and every delete merges them back. Both need space. Microsoft's checklist: "Check for storage exhaustion on volumes that store .vhdx, .avhdx, .mrt, or .rct files" and "Make sure that sufficient free space exists for merges (ideally, space equal to the disk size)."

# Read-only. Free space on every volume on the host
Get-Volume | Where-Object DriveLetter |
  Sort-Object SizeRemaining |
  Format-Table DriveLetter, FileSystemLabel, FileSystem,
    @{n='SizeGB';e={[math]::Round($_.Size/1GB,1)}},
    @{n='FreeGB';e={[math]::Round($_.SizeRemaining/1GB,1)}} -AutoSize

# Read-only. Size of every disk file in the VM folder (biggest first)
Get-ChildItem -Path 'V:\Hyper-V\APP02' -Recurse -Include *.vhdx, *.avhdx, *.vhd, *.avhd, *.mrt, *.rct |
  Sort-Object Length -Descending |
  Format-Table @{n='SizeGB';e={[math]::Round($_.Length/1GB,2)}}, LastWriteTime, FullName -AutoSize

How to read it:

Reading	What it means	Next
Volume free space below the size of the VM's largest disk	A merge may not have room to finish (Microsoft's "ideally, space equal to the disk size")	Free or add space before you delete checkpoints (Step 9)
A large .avhdx with a recent LastWriteTime	The VM is still writing to a differencing disk, so a checkpoint is still in its chain	Step 7: is that checkpoint visible?
Many .avhdx files, old dates	Leftover checkpoints from backups or forgotten manual ones	Step 7
Cluster Shared Volume	The CSV itself has to be healthy	Microsoft: "Check CSV and cluster resource status"

Microsoft's quick reference also covers the case where there's no space to merge and the VM won't start: "Free up storage, attach USB/NAS, perform merge and export."

---

Step 6: Permissions, antivirus, and file locks (read-only)

Microsoft's checklist: "Verify that the NT VIRTUAL MACHINE\Virtual Machines group has the 'Log on as a Service' privilege and NTFS folder permissions," and "Review antivirus exclusions for Hyper-V-related files and folders."

# Read-only. Who can write the VM folder and the checkpoint folder? (icacls with just a path displays the DACL)
icacls 'V:\Hyper-V\APP02'
icacls 'V:\Hyper-V\APP02\Snapshots'

# Read-only. The VM's ID, which is the name in its per-VM account NT VIRTUAL MACHINE\<VMId>
(Get-VM -Name 'APP02').VMId

Microsoft's permission fix grants NT VIRTUAL MACHINE\<VMGuid> full control on the VM folder. Reading the ACL first tells you whether that's actually missing. A folder copied by hand during a storage move often loses that entry (our reading).

For Log on as a service, Microsoft's policy location is Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment. A domain GPO that sets this right replaces the local list. If the GPO doesn't include NT VIRTUAL MACHINE\Virtual Machines, Hyper-V loses it after the next refresh (our reading of how user-rights GPOs apply). Read the effective policy with gpresult /h or the GPO itself before editing anything.

For antivirus, Microsoft's Hyper-V exclusion list covers .vhd, .vhdx, .avhd, .avhdx, .vhds, .rct, .mrt, .vsv, .bin, .vmcx, .vmrs, and .vmgs files, the default and custom VM and checkpoint folders, C:\ClusterStorage, and the processes Vmms.exe, Vmwp.exe, Vmsp.exe, and Vmcompute.exe. Microsoft notes that if you use Windows Defender you "may not need to configure additional exclusions" because of its automatic exclusions. For a third-party product, compare its policy against that list.

For 0x80070020 (file in use), Microsoft's fix is to "Use Resource Monitor or ProcMon to identify the process that locks the file." Read who holds it before you restart anything. It's usually the backup agent or an AV scanner, not Hyper-V (our reading).

---

Step 7: The existing checkpoint chain (read-only)

Most "can't delete" and "can't merge" tickets are here. Start with what Hyper-V knows about:

# Read-only. Every checkpoint Hyper-V tracks for this VM, oldest first
Get-VMSnapshot -VMName 'APP02' |
  Sort-Object CreationTime |
  Format-Table Name, SnapshotType, CreationTime, ParentSnapshotName -AutoSize

# Read-only. Only checkpoints of type Recovery (the type backup tools usually create, our reading)
Get-VMSnapshot -VMName 'APP02' -SnapshotType Recovery

Get-VMSnapshot -SnapshotType accepts Standard, Recovery, Planned, Missing, Replica, AppConsistentReplica, and SyncedReplica. Microsoft lists the values without defining each one. Backup tools usually create "recovery checkpoints" (Microsoft's backup article quotes Failed to create VM recovery checkpoint), and Microsoft's merge article notes Delete Checkpoint can be missing from the context menu when "third-party backup software generates checkpoints but doesn't delete them." The Delete key still works on those.

Then compare with what's on disk. Microsoft's guide reads the chain like this:

# Read-only. The disk each VM controller points at, and its parent chain (Microsoft's troubleshooting pattern)
Get-VMHardDiskDrive -VMName 'APP02' | ForEach-Object {
  Get-VHD -Path $_.Path | Select-Object Path, ParentPath, VhdType
}

# Read-only. Every disk file in the VM folder, with its parent, to find .avhdx files Hyper-V Manager doesn't show
Get-ChildItem -Path 'V:\Hyper-V\APP02' -Recurse -Include *.vhd, *.vhdx, *.avhd, *.avhdx |
  Get-VHD | Format-Table Path, VhdType, ParentPath -AutoSize

# Read-only. Is the chain that starts at the VM's current disk usable?
Test-VHD -Path 'V:\Hyper-V\APP02\APP02_7C1E....avhdx'

Test-VHD "tests a virtual hard disk for any problems that would make it unusable," and Microsoft's example tests the chain that starts at a differencing disk. Get-VHD has one catch from its page: when a VHD is in use on shared storage, only the host using it can read it. Run these on the owning node.

How to read the chain:

Reading	What it means	Next
The VM's disk Path ends in .avhdx	The VM is running on a differencing disk; at least one checkpoint is in the chain	Is it in Get-VMSnapshot? If not, it's orphaned
.avhdx files not listed by Get-VMSnapshot	Microsoft: orphaned or hidden checkpoints, "usually from backup software"	Shutdown merge or Merge-VHD (Step 9)
A ParentPath that doesn't exist	Broken chain	Microsoft: restore the missing disk from backup if possible
Get-VHD or Test-VHD errors on one file	That differencing disk is likely damaged (our reading)	Microsoft's merge article: if Get-VHDChain reports errors, you have to remove the affected differencing disks from the folder before merging. Back everything up before that
More than 50 checkpoints	Microsoft: schedule downtime and merge from youngest to oldest	Step 9

Microsoft's merge article also has a Get-VHDChain function. It walks every VM's disks through ParentPath and reports any disk it can't read as Error. It's worth running before a large manual merge.

---

Step 8: Read the event logs (read-only)

Microsoft's data collection list for checkpoint issues names the Application, System, and Microsoft-Windows-Hyper-V-VMMS/Admin logs.

# Read-only. Find the exact Hyper-V log names on this host (names vary slightly by version)
Get-WinEvent -ListLog '*Hyper-V-VMMS*', '*Hyper-V-Worker*' |
  Format-Table LogName, RecordCount, IsEnabled -AutoSize

# Read-only. Last 24 hours of VMMS and worker errors and warnings that mention checkpoints, snapshots, or VSS
$since = (Get-Date).AddDays(-1)
Get-WinEvent -FilterHashtable @{ LogName = 'Microsoft-Windows-Hyper-V-VMMS-Admin', 'Microsoft-Windows-Hyper-V-Worker-Admin'; Level = 2, 3; StartTime = $since } -ErrorAction SilentlyContinue |
  Where-Object { $_.Message -match 'checkpoint|snapshot|VSS|APP02' } |
  Format-Table TimeCreated, LogName, Id, Message -Wrap

The -Admin log names are how these channels usually appear to Get-WinEvent (our reading; use whatever -ListLog returned). Community threads often quote VMMS event IDs such as 18012 and 18014 for failed checkpoints. We haven't found a Microsoft Learn page that documents them, so read the message text rather than the ID. Then read the guest's Application log for VSS errors (Event ID 12293, per Microsoft's backup article) at the same minute.

If the VM is stuck at "creating checkpoint," Microsoft's quick reference names SnapshotTask / VMDeltaSync stuck and the VMMS service blocked as the cause, and "Restart host, kill stuck processes, analyze dump files" as the fix. That's a maintenance-window change, not a first move.

---

Common false starts (read these before you change anything)

False start	Why it hurts	Read-first alternative
Deleting .avhdx files to free space	Microsoft: "You should not delete the .avhdx files directly." The VM may be running on that file, and the newest data lives there	Delete the checkpoint (which merges), or shut down and let the merge run (Step 9)
Applying a checkpoint to "get back to working"	Microsoft's apply dialog: Apply "cannot undo this action." Standard checkpoints "can cause data consistency issues" with replicated systems "such as Active Directory"	Leave apply for rollback decisions, never as troubleshooting
Switching to Standard so backups "work"	It hides a broken guest VSS path, and backups lose application consistency (our reading)	Fix guest VSS (Step 3); test with ProductionOnly (Step 9)
Disabling checkpoints on the VM	Microsoft: Disabled blocks creation of checkpoints, which can include the backup tool's (our reading)	Clean up old checkpoints instead
Restarting VMMS or the host first	Clears the symptom, erases the evidence, and doesn't fix a failed guest writer or a missing permission	Read Steps 3-8 first; restart only for a stuck task (Step 8)
Running Merge-VHD on a running VM's disks	Microsoft: "Merge is an offline operation; the virtual hard disk chain must not be attached when merge is initiated"	Shut down, or follow Microsoft's online merge procedure step by step
Merging in the wrong order	Microsoft: merge differencing disks "one by one, from child to parent"	Map the chain first (Step 7)
Granting Everyone full control on the VM folder	Fixes the error by weakening the host	Grant only the VM's own account, as Microsoft's fix does
Turning off AV completely	Removes protection from the host	Add Microsoft's documented exclusions

---

Step 9: Change one layer, then watch (only after the read)

Back up first. Microsoft: "Always back up critical VMs before performing file merges, deletions, or major configuration changes," and for chain repairs, "Back up all files before you try any fixes." Pick the one change Steps 1-8 point at. Every Hyper-V cmdlet below supports -WhatIf. Run it with -WhatIf first, then without.

# Change (elevated on HV01). Pick ONE that matches your finding

# Test production checkpoints without the silent fallback (Step 2/3 isolation test)
Set-VM -Name 'APP02' -CheckpointType ProductionOnly -WhatIf
Checkpoint-VM -Name 'APP02' -SnapshotName 'Test-ProductionOnly-20261017' -WhatIf
# If the test checkpoint succeeds, delete it (this merges it) and put the type back
Remove-VMSnapshot -VMName 'APP02' -Name 'Test-ProductionOnly-20261017' -WhatIf
Set-VM -Name 'APP02' -CheckpointType Production -WhatIf

# Checkpoints were disabled on the VM: re-enable deliberately
Set-VM -Name 'APP02' -CheckpointType Production -WhatIf

# VSS integration service disabled on the host side
Enable-VMIntegrationService -VMName 'APP02' -Name 'VSS' -WhatIf

# Checkpoint file location missing after a storage move (only possible when the VM has no checkpoints)
Set-VM -Name 'APP02' -SnapshotFileLocation 'V:\Hyper-V\APP02' -WhatIf

# Change INSIDE the guest (elevated). Requestor or VSS stuck; Microsoft's backup article restarts VSS and swprv
Restart-Service -Name vmicvss -WhatIf
Restart-Service -Name VSS, swprv -WhatIf

Restart-Service supports -WhatIf and -Confirm. Microsoft's article runs net stop / net start for vss and swprv. The PowerShell equivalent is ours. If a guest application writer is the one in [9] Failed, restart that application's service in its own maintenance window instead (our advice). Then re-run vssadmin list writers.

Cleaning up old checkpoints (visible in Hyper-V Manager):

# Change. Delete (and merge) one named checkpoint, or old ones by date. -WhatIf lists exactly what would go
Remove-VMSnapshot -VMName 'APP02' -Name 'Before-Patch-20260801' -WhatIf
Get-VMSnapshot -VMName 'APP02' |
  Where-Object { $_.CreationTime -lt (Get-Date).AddDays(-30) } |
  Remove-VMSnapshot -WhatIf

The date filter is Microsoft's own Remove-VMSnapshot example (it uses 90 days). -IncludeAllChildSnapshots deletes the checkpoint's children too, so leave it off unless you mean it. Watch the VM's status in Hyper-V Manager (in our experience it shows merge progress) and the volume's free space (Step 5) while it runs.

Orphaned .avhdx files (not visible in Hyper-V Manager):

Microsoft's order: shut the VM down first, because "typically, the differencing disk files merge as part of the VM shutdown process." Only if files remain after a clean shutdown, merge them by hand.

# Change. 1) Clean guest shutdown, which often merges orphaned differencing disks
Stop-VM -Name 'APP02' -WhatIf

# 2) Only if .avhdx files remain: merge child to parent, VM OFF, chain mapped in Step 7, files backed up
Merge-VHD -Path 'V:\Hyper-V\APP02\APP02_7C1E....avhdx' -DestinationPath 'V:\Hyper-V\APP02\APP02.vhdx' -WhatIf

Stop-VM without -TurnOff asks the guest to shut down. With -Force, applications with unsaved data get five minutes. -TurnOff is a power pull, so avoid it here (our advice). Microsoft's Merge-VHD example also notes the merged-from files "are not deleted, however, they are no longer valid virtual hard disk files after the operation completes." After a manual merge, Microsoft says to update the VM's configuration to point at the merged .vhdx, if necessary, before you start it. Leave the old files in place until the VM boots cleanly and a backup runs. If you can't shut the VM down at all, Microsoft's merge article has a multi-step online procedure (back up the files, run Get-VHDChain, generate the merge commands, re-point the VM). Follow it exactly, or wait for a window.

Permissions (no -WhatIf in icacls, so print the command first):

# Change helper (ours). Prints the icacls command under -WhatIf; runs it only without -WhatIf
function Grant-VMFolderAccess {
  [CmdletBinding(SupportsShouldProcess, ConfirmImpact = 'High')]
  param(
    [Parameter(Mandatory)] [string] $VMName,
    [Parameter(Mandatory)] [string] $Folder
  )
  $id = (Get-VM -Name $VMName).VMId
  $acct = "NT VIRTUAL MACHINE\$id"
  if ($PSCmdlet.ShouldProcess($Folder, "icacls /grant ${acct}:F /T")) {
    icacls $Folder /grant "${acct}:F" /T
  }
}

Grant-VMFolderAccess -VMName 'APP02' -Folder 'V:\Hyper-V\APP02' -WhatIf

That matches Microsoft's documented fix (icacls <PathToVMFolder> /grant "NT VIRTUAL MACHINE\<VMGuid>:F" /T). The wrapper is ours. Per icacls, /grant without :r adds to the existing explicit permissions instead of replacing them. If "Log on as a service" is the gap, fix it in the GPO that owns the right (Step 6), then run gpupdate /force as Microsoft's guide says.

Read-only confirm afterwards:

Get-VMIntegrationService -VMName 'APP02' -Name 'VSS' | Format-Table Name, Enabled, PrimaryStatusDescription -AutoSize
Get-VMSnapshot -VMName 'APP02' | Format-Table Name, SnapshotType, CreationTime -AutoSize
Get-VMHardDiskDrive -VMName 'APP02' | ForEach-Object { Get-VHD -Path $_.Path | Select-Object Path, ParentPath, VhdType }

Changes outside Hyper-V:

• Backup tool: make sure jobs clean up their checkpoints, stagger schedules so VSS operations don't overlap, and use the vendor's own checkpoint cleanup tool for its leftovers (Microsoft's article gives Veritas nbhypervtool.exe as an example).
• Antivirus: add Microsoft's Hyper-V exclusions in the AV console, not by switching scanning off.
• Storage: add or free space so merges have room, then clean up checkpoints.

Watch one full cycle: the next backup job creates and removes its checkpoint, Get-VMSnapshot shows no new leftovers, the VM's disk Path points back at the .vhdx, and no new checkpoint errors show up in the VMMS log.

---

When a change is justified

Finding	Prefer	Avoid
Production checkpoints cannot be created, guest writer failed	Fix or restart the failed writer's service in the guest; re-test with ProductionOnly	Switching the VM to Standard permanently
VSS integration service disabled in the guest	Re-enable it in the guest policy, then on the host	Leaving production checkpoints falling back to standard
Old checkpoints visible in Hyper-V Manager	Remove-VMSnapshot one at a time, space checked	Deleting .avhdx files in Explorer
Orphaned .avhdx from the backup tool	Clean shutdown, then a child-to-parent Merge-VHD if needed	Merging while the VM is running, or out of order
Volume too full to merge	Free or add space, or move the VM first	Starting a merge that runs out of room
VM account missing from the folder ACL	Grant only NT VIRTUAL MACHINE\<VMId>	Everyone or Authenticated Users full control
AV locking .avhdx files	Microsoft's exclusions	Disabling AV on the host
Pass-through or shared VHDX disk	In-guest backup for that disk, or convert to .vhdx	Expecting checkpoints to work on it
VM stuck at "creating checkpoint"	Planned host restart after reading Step 8	Killing worker processes during business hours

---

FAQ

What does "Hyper-V checkpoint operation failed" mean?
It's the generic wrapper. The line under it says why: a VSS failure inside the guest, an unsupported disk, a missing or unwritable checkpoint folder, a file lock (0x80070020), no space, or a broken differencing-disk chain. Read the full error, Get-VMIntegrationService for the VSS line, and the Hyper-V VMMS Admin log before you change anything.

Why can't Hyper-V create a production checkpoint?
Production checkpoints use VSS inside the guest (or File System Freeze on Linux). Check that the VSS integration service is enabled on the host and in the guest, that the Hyper-V Volume Shadow Copy Requestor is running, and that vssadmin list writers inside the guest shows no failed writers. If the VM is set to Production, Hyper-V quietly falls back to a standard checkpoint. ProductionOnly makes the failure visible.

Can I delete .avhdx files to free up space?
No. Microsoft says not to delete .avhdx files directly. They hold the changes since the checkpoint, and the VM may be running on one. Delete the checkpoint in Hyper-V Manager or with Remove-VMSnapshot, which merges it. For files that don't show up in Hyper-V Manager, shut the VM down so the merge can run, then use Merge-VHD child-to-parent if any remain.

Why won't my Hyper-V checkpoint delete or merge?
Usually because a backup tool created it and didn't clean up, a process holds the file, the volume doesn't have room to merge, or the chain is broken. Microsoft's order: try Delete (or the Delete key), shut the VM down to trigger the merge, then merge with Edit Disk or Merge-VHD child-to-parent, with backups of every file first.

What does "could not initiate a checkpoint operation" mean?
Hyper-V couldn't start the checkpoint at all. In the cases we see, it couldn't create the new differencing disk or reach the VM's files (our reading). Check the checkpoint file location exists, the volume has space, icacls shows the VM's NT VIRTUAL MACHINE\<VMId> account on the folder, and antivirus excludes Hyper-V files. Then read the VMMS Admin log for the inner error.

---

Related posts

• Trust Relationship Between This Workstation and the Primary Domain Failed (what happens when someone applies an old standard checkpoint to a domain member)
• Retention Is Not Backup (a checkpoint isn't a backup either; the same restore-drill habit)
• Build a Small M365 + Intune Home Lab (a safe Hyper-V lab to practice checkpoints, merges, and VSS failures before you touch production)

Free checklist

Most checkpoints are taken right before a change window. If the change you're about to make is Conditional Access enforcement, a checkpoint won't roll back a tenant policy. The free Conditional Access pre-enforcement checklist keeps break-glass accounts, pilot groups, and report-only review on one page:

👉 https://cashflow4375.gumroad.com/l/ujkqxb?utm_source=devto&utm_medium=article&utm_campaign=aps_first_sale&utm_content=hyperv-checkpoint-failed

If you want the rest of the Intune runway written down for the team (enrollment hygiene, compliance phasing, break/fix cards and read-only PowerShell snapshots), the Intune & M365 Admin Starter Pack pairs with this triage: https://cashflow4375.gumroad.com/l/joonf?utm_source=devto&utm_medium=article&utm_campaign=aps_first_sale&utm_content=hyperv-checkpoint-failed

---

Admin Pack Studio; not affiliated with Microsoft. Steps 1-8 favor read-only checks: Get-VM, Get-VMHardDiskDrive, Get-VMIntegrationService, Get-Service, vssadmin list writers, Get-Volume, Get-ChildItem, icacls (display only), Get-VMSnapshot, Get-VHD, Test-VHD, and Get-WinEvent. Changing checkpoint types or locations, enabling integration services, restarting services, creating or removing checkpoints, shutting down VMs, merging disks, granting permissions, and AV or backup-tool changes are deliberate changes. Back up first, change one layer at a time, watch one backup cycle, and check current Microsoft Learn for version-specific behavior.