0xC0370027 and 0xC0370104: saved state and checkpoint data cannot be read

Fix it now

The machine has state on disk that no longer matches the machine trying to load it. Either the saved memory image cannot be read back, or a checkpoint chain is broken so the disk the machine expects is not the disk it finds. Copy the whole folder somewhere safe before you touch either.

Get-VM 'Server1' | Select-Object Name, State, Version
Get-VHD 'D:\VMs\Server1\disk_A1B2.avhdx' | Select-Object Path, ParentPath, VhdType
Get-VMHostSupportedVersion

1. If the machine is in a saved state you do not need, discard it with Remove-VMSavedState -VMName 'Server1' and start it normally. It boots as though it had been powered off abruptly, so expect the guest to run its own consistency checks.
2. If checkpoints are involved, read the ParentPath the second command reports and confirm that file exists at exactly that path.
3. If the folder was moved, repoint the child at its parent with Set-VHD -Path '<child>' -ParentPath '<parent>' rather than editing anything by hand.
4. If a checkpoint is showing in Hyper-V Manager, delete it there so the merge runs, and leave the host alone until the merge finishes.

Discarding saved state loses everything the guest held in memory, exactly as a power cut would. Repointing a differencing disk at a file that is not really its parent can corrupt the guest file system beyond recovery.

If the machine boots, stop here. If it will not, or the version numbers do not line up between hosts, the next section explains what has to match what.

Why it happens

A saved virtual machine writes the whole of its memory and its device state to files beside the configuration. Restoring it means reloading that image into a machine with the same virtual hardware. If the configuration has changed, if only part of the file set was restored from backup, or if the files came from a host generation that does not match, the reload fails and the machine sits refusing to start or resume.

Checkpoints work differently. Each one creates a differencing disk that records only what changed and points back at its parent by both path and identifier. The chain from the newest differencing disk down to the base disk has to be complete and consistent. Restoring only the base disk, moving the folder without Hyper-V, or copying some files but not others leaves a machine that cannot resolve its own storage.

Both codes on this page are unpublished, which is unhelpful and also not much of a loss, because the entries beside them carry the file path the host could not follow. That path is the diagnosis. Start from it rather than from the number, and the two cases separate themselves immediately: a path into the saved state files is one problem and a path into an AVHDX chain is the other.

Full reference

What is on disk, and what has to match

Reading the chain

Get-VM 'Server1' | Get-VMHardDiskDrive | Select-Object VMName, Path
Get-VHD 'D:\VMs\Server1\disk_A1B2.avhdx' | Select-Object Path, ParentPath, VhdType, FragmentationPercentage

Follow ParentPath from the newest file down to a base disk whose type is not differencing. Every link has to resolve to a file that exists at exactly that path. If one does not, you have found the break. Do this before starting the machine, not after, because a machine that starts on a half-resolved chain writes into it.

Order of operations when you are not sure

1. Copy the entire virtual machine folder, including every VHDX and AVHDX and the configuration, to somewhere with space for it.
2. Read the chain and write down what points at what, so you can tell later whether a change helped.
3. Deal with saved state first if there is any, because discarding it takes one variable out of the problem.
4. Restore the file layout the chain expects rather than repointing, wherever the files still exist.
5. Repoint only when the path genuinely cannot be restored, and only after the copy in step one.
6. Merge outstanding checkpoints through the console once the chain resolves, and leave the host alone while it runs.

Configuration versions between hosts

A machine carries a configuration version, and a host supports a range of them. A machine from a newer host will not run on an older one, and there is no downgrade path: Update-VMVersion raises the version and nothing lowers it. Get-VMHostSupportedVersion on each host tells you what that host will accept, which is worth checking before a move rather than after a failed one. In a mixed-version estate this is a recurring source of machines that will not start on the host they were just moved to, and the fix is to move them back rather than to force anything.

Why AVHDX files are not clutter

They hold everything written since the checkpoint they belong to. Deleting one discards that data, and if the guest has been running on the chain, the base disk underneath is far out of date: you would be reverting the machine by however long the checkpoint has existed. Merge through the console instead, which writes the changes down into the parent and then removes the file. A folder full of AVHDX files that nobody recognises is a merge that never completed, not a cleanup opportunity.

None of this is a licensing or edition question. Saved state and checkpoints behave identically on Standard and Datacenter; edition affects how many virtual machines you may run on the host, not how their state is stored.

Every code this article covers

Confirm the fix worked

1. The machine starts and the guest operating system comes up with its services running.
2. Get-VM 'Server1' | Select-Object Name, State, Version reports it running with no saved state remaining.
3. Get-VHD against each disk resolves the whole chain, or there is now a single base disk.
4. No differencing files remain in the folder that no longer belong to the machine.
5. The machine’s configuration version is within the range Get-VMHostSupportedVersion reports on this host.

Questions people ask about this