| Previous | Next |
| ERROR_VOLMGR_VOLUME_CONTAINS_MISSING_DISK | ERROR_VOLMGR_VOLUME_LENGTH_INVALID |
ERROR_VOLMGR_VOLUME_ID_INVALID
Locate the rejected storage invariant: volmgr volume id invalid
The practical meaning of ERROR_VOLMGR_VOLUME_ID_INVALID (0xC0380046) is tied to logical volume geometry and the disk extents that realize it: the volume identifier does not resolve to a volume in the selected pack generation. The result does not, by itself, prove file-system corruption or physical-media failure while diagnosing this result.
Dynamic volumes are represented as packs containing disks and volumes; each volume has one or more plexes, and each plex is assembled from members and extents. Indices and counts are relative to the submitted layout generation, while configuration logs are replicated across participating dynamic disks. This object model determines which identifiers, counts and ownership state are meaningful for this HRESULT.
The standard message identifies the immediate condition, but this result also requires the producer API, object topology and attempted state transition. Capture them before an automatic refresh advances the storage generation while diagnosing it.
Evidence to preserve before repair
| Storage diagnostic field | Value |
|---|---|
| Identity and generation | volume ID, requested length, sector sizes, extent table, plex/member counts, disk health and the exact VM_VOLUME_LAYOUT buffer |
| Narrow experiment | serialize the exact VM_VOLUME_LAYOUT buffer, validate every count and Size field, and compare it with a layout produced by a known-good management API |
| Closest comparison | ERROR_VOLMGR_UNEXPECTED_DISK_LAYOUT_CHANGE |
| Owning object | logical volume geometry and the disk extents that realize it |
| Rejected invariant | the volume identifier does not resolve to a volume in the selected pack generation |
Keep this HRESULT as the primary result if rollback or cleanup reports another code; those later values describe recovery, not the first rejected invariant while diagnosing this result.
One-variable reproduction
- Associate this result with one caller, one transaction and one target UniqueId.
- Save the pre-call and post-call inventories, including volume ID, requested length, sector sizes, extent table, plex/member counts, disk health and the exact VM_VOLUME_LAYOUT buffer.
- Use this A/B case for this HRESULT without touching unrelated storage: serialize the exact VM_VOLUME_LAYOUT buffer, validate every count and Size field, and compare it with a layout produced by a known-good management API while diagnosing it.
- Validate both the HRESULT and the on-disk or provider state after the relevant reopen, remount or attach cycle for this HRESULT.
Compare traces for ERROR_VOLMGR_UNEXPECTED_DISK_LAYOUT_CHANGE and it. The latter page covers a nearby storage boundary, whereas it rejects the volume identifier does not resolve to a volume in the selected pack generation while diagnosing it. A correct caller should be able to reproduce each case independently while diagnosing it.
Mechanism-specific note
The identifier must be resolved in the same enumeration generation and provider scope that will execute the operation. Store the stable GUID plus the pack generation. Drive letters, friendly names and array positions are unsuitable substitutes because they can change independently of the underlying dynamic-volume object.
Repair without rewriting unrelated metadata
Refresh the disk layout, serialize the change as one volume-manager transaction and reject any external partition mutation until commit or rollback completes for this HRESULT. After correcting it, reopen the pack, volume, tier, snapshot or virtual disk so no cached generation participates in the validation run.
- The original request now reaches success or a documented later status with the intended layout and access mode.
- A new enumeration reports internally consistent IDs, counts, geometry and ownership for the object corrected after it.
- The passing state survives the lifecycle transition relevant to it, such as reopen, remount, owner change or detach/attach.
- The application still distinguishes it from
ERROR_VOLMGR_UNEXPECTED_DISK_LAYOUT_CHANGEand has no unbounded retry loop.
Do not use it as a reason to edit dynamic-disk sectors, VHDX metadata, RCT sidecars or snapshot support files directly while diagnosing it. Unsupported edits can turn a recoverable state mismatch into persistent corruption.
Technical references
- Microsoft: COM error codes for VOLMGR, VHD and SDIAG — use this source to verify volmgr state and parameters for this HRESULT.
- Microsoft: Virtual Disk Service object model — documents the supported management path relevant to it.
- Microsoft: Pack object — defines the volmgr objects used to interpret it.
- Microsoft: Virtual Disk Service common return codes — primary API or object-model reference for the boundary.
Looking for a different code? Search another status or error code.