| Previous | Next |
| ERROR_VID_SAVED_STATE_UNRECOGNIZED_ITEM | ERROR_VID_VTL_ACCESS_DENIED |
ERROR_VID_SAVED_STATE_INCOMPATIBLE
ERROR_VID_SAVED_STATE_INCOMPATIBLE is HRESULT 0xC0370029 in the Hyper-V saved-state host compatibility area of the Windows virtualization stack. It applies to restoring a VM runtime state whose processor, configuration, device, or hypervisor assumptions do not match the current host.
State and ownership model
The saved state can be present and intact yet unusable on this host. Compare CPU features, Hyper-V/Windows build, VM configuration version, and device capabilities before treating the file as corrupt.
Neighboring result: SAVED_STATE_CORRUPT is an integrity problem; UNRECOGNIZED_ITEM is a format-record problem. INCOMPATIBLE is a supported-capability mismatch between saved assumptions and the restore environment.
Capture before changing anything
| Evidence | Why it changes the diagnosis |
|---|---|
| Host compatibility | Record source/target CPU vendor and features, Windows build, firmware virtualization settings, and Hyper-V updates. |
| VM version | Keep configuration version, generation, processor compatibility mode, and feature settings. |
| Migration path | Record whether the VM was saved, exported, copied, restored, or failed during live migration. |
| Device/state dependencies | Capture assigned devices, virtual TPM/VBS features, and checkpoints. |
Reduce the case safely
- Use Compare-VM/import compatibility tools before changing files.
- Apply processor compatibility mode before save/migration when the scenario supports it.
- Move to a host that supports the VM configuration and saved processor features.
- Discard saved state only after accepting loss of volatile guest state.
Work from copies during diagnosis. Before changing its state, capture source host, target host, VM version, processor features, storage integrity, and relevant event logs.
What comparison can tell you
| Control | Interpretation | Hold constant |
|---|---|---|
| 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. |
| 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. |
Do not erase the evidence
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.
Closure criteria
The original state restores on a compatible host or the VM starts cleanly after an explicit state reset, and subsequent mobility tests pass across all intended hosts.
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.