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 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:

Then match the symptom:

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

Microsoft documents four values for Set-VM -CheckpointType:

# 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:

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:

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:

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:

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)

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

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.