| Previous | Next |
| ERROR_VID_MBP_COUNT_EXCEEDED_LIMIT | ERROR_VID_SAVED_STATE_UNRECOGNIZED_ITEM |
ERROR_VID_SAVED_STATE_CORRUPT
ERROR_VID_SAVED_STATE_CORRUPT is HRESULT 0xC0370027 in the Hyper-V saved runtime state integrity area of the Windows virtualization stack. It applies to reading the VM saved runtime state needed to restore processor, device, and memory execution state.
What the code establishes
The saved-state data cannot be parsed or validated as an intact state image. The virtual disks are a separate asset; deleting saved state abandons in-memory execution state but does not repair or rewrite guest disk contents.
Neighboring result: SAVED_STATE_UNRECOGNIZED_ITEM can identify an unknown record, while SAVED_STATE_INCOMPATIBLE indicates a valid-looking state that the current hypervisor cannot use. CORRUPT is an integrity/readability failure.
Evidence that should survive remediation
| Evidence | Why it changes the diagnosis |
|---|---|
| VM identity and files | Record VM ID, configuration path, saved-state file paths, sizes, timestamps, and storage health. |
| First failing event | Preserve Hyper-V-VMMS/Admin and Hyper-V-Worker/Admin event chain. |
| Storage history | Note abrupt power loss, antivirus/filter activity, backup restore, copy, and disk errors. |
| Independent assets | Inventory VMCX/configuration, VMRS/VMGS runtime state, checkpoints, and VHDX separately. |
Controlled diagnostic sequence
- Copy or back up the affected state files before destructive recovery.
- Verify host storage and file permissions before attributing corruption to the VM.
- Use Remove-VMSavedState only after accepting loss of volatile guest state.
- Start from disks or a known-good checkpoint and validate guest/application consistency.
Work from copies during diagnosis. Before changing its state, capture source host, target host, VM version, processor features, storage integrity, and relevant event logs.
Read the comparison tests
| Control | Interpretation | Hold constant |
|---|---|---|
| Original host versus destination | If it restores only on the source host, compare CPU features, Windows build, configuration version, and virtual devices. | Use an untouched copy of the saved-state and configuration files. |
| Supported compatibility check | Compare-VM, import checks, or configuration-version data can separate compatibility problems from unreadable state. | Preserve source/target host facts before upgrading or discarding state. |
| Boot after explicit state discard | Starting from virtual disks can establish that it is confined to volatile runtime state, but it deliberately loses that state. | Copy the affected state first and do not call this a format repair. |
Avoid the wrong recovery
Do not delete saved state merely to clear it before making a copy and accepting loss of volatile guest state. In a recovery, virtual disks remain separate, but guest applications may still require consistency checks after boot.
Acceptance test
Recovery is complete when the VM starts through a supported path, storage checks are clean, and future save/restore cycles succeed; merely deleting evidence is not proof of root cause.
Technical references
These sources define it and the compatibility, processor, and saved-state recovery boundaries used in the diagnosis.
- Microsoft Open Specifications: HRESULT values — used to interpret this result.
- Microsoft: Remove-VMSavedState — used to interpret this result.
- Microsoft: VM configuration version compatibility — used to interpret this result.
- Microsoft: Hyper-V processor compatibility — used to interpret this result.
Looking for a different code? Search another status or error code.