| 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. The built-in message names the immediate result; the useful custom context is the exact boundary: restoring a VM runtime state whose processor, configuration, device, or hypervisor assumptions do not match the current host. Record the first returning operation and host-side event before a management layer retries or translates it.
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.
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_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. |
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.
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 while diagnosing this result. Before changing it state, capture source host, target host, VM version, processor features, storage integrity, and relevant event logs.
What comparison can tell you
Across these controls for it, preserve restoring a VM runtime state whose processor, configuration, device, or hypervisor assumptions do not match the current host as the boundary under test.
| Control | Interpretation | Hold constant |
|---|---|---|
| Supported compatibility check — this result | 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. |
| Original host versus destination — it | 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. |
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 it 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. 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.