| 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. The built-in message names the immediate result; the useful custom context is the exact boundary: reading the VM saved runtime state needed to restore processor, device, and memory execution state. Record the first returning operation and host-side event before a management layer retries or translates it.
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.
Hyper-V architecture documentation identifies VID as the component that provides partition, virtual-processor, and memory-management services., many ERROR_VID_* values describe internal host objects rather than a public API that administrators should call directly. Accordingly, diagnose this result through the named object/state, the VMMS or Worker event chain, and the operation that produced it; do not invent a user-mode VID call from the constant name.
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. |
Preserve identifiers and counts without dumping guest secrets or unrelated memory. Useful this result timestamps include the last successful operation, first failure, any automatic retry, and the object-generation change that followed.
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 while diagnosing this result. Before changing it state, capture source host, target host, VM version, processor features, storage integrity, and relevant event logs.
Read the comparison tests
Across these controls for it, preserve reading the VM saved runtime state needed to restore processor, device, and memory execution state as the boundary under test.
| Control | Interpretation | Hold constant |
|---|---|---|
| Original host versus destination — this result | 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 for it. |
| Supported compatibility check — it | Compare-VM, import checks, or configuration-version data can separate it incompatibility from unreadable state. | Preserve source/target host facts before upgrading or discarding state. |
| Boot after explicit state discard — it | 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 for it. |
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 it 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. Repeat the original operation under the original supported conditions and retain one deliberate negative control. A management command succeeding on a different object is not sufficient to close this incident.
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 the boundary.
- Microsoft: Remove-VMSavedState — used to interpret the boundary.
- Microsoft: VM configuration version compatibility — used to interpret the boundary.
- Microsoft: Hyper-V processor compatibility — used to interpret the boundary.
Looking for a different code? Search another status or error code.