| Previous | Next |
| ERROR_VOLMGR_FAULT_TOLERANT_NOT_SUPPORTED | ERROR_VOLMGR_MAXIMUM_REGISTERED_USERS |
ERROR_VOLMGR_INTERLEAVE_LENGTH_INVALID
Interpret the state transition: volmgr interleave length invalid
ERROR_VOLMGR_INTERLEAVE_LENGTH_INVALID has unsigned value 0xC0380021. In the volmgr layer, it rejects a specific contract because the stripe interleave value violates the volume-manager alignment or supported stripe-unit constraints. Diagnosis of this result should follow kernel volume-manager layout transaction and VM_VOLUME_LAYOUT input through one controlled state transition.
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 while diagnosing this result. This object model determines which identifiers, counts and ownership state are meaningful.
Diagnosis of this result should begin with the object model and generation current at the failure. A later successful enumeration may describe a replacement object and cannot retroactively validate the rejected request.
Record geometry, identity and ownership
| Storage diagnostic field | Value |
|---|---|
| Rejected invariant | the stripe interleave value violates the volume-manager alignment or supported stripe-unit constraints |
| Identity and generation | pack and volume IDs, input structure version and sizes, transaction ID, disk-layout snapshot before the call and the first kernel storage event |
| 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 | kernel volume-manager layout transaction and VM_VOLUME_LAYOUT input |
Do not overwrite this result with a close, detach or rollback error. Preserve the causal order so the original storage contract remains visible.
Separate validation from capability
- Create a nonproduction case for this HRESULT that preserves the same geometry and ownership model for this HRESULT.
- Collect pack and volume IDs, input structure version and sizes, transaction ID, disk-layout snapshot before the call and the first kernel storage event before invoking the first mutating API.
- Change one condition only: 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.
- Re-enumerate after the transition and confirm it is not reproduced by a stale handle from the old generation.
The distinction from ERROR_VOLMGR_UNEXPECTED_DISK_LAYOUT_CHANGE is operational. The decisive condition is the stripe interleave value violates the volume-manager alignment or supported stripe-unit constraints; log the neighboring code separately so capability, identity and state are not conflated.
Mechanism-specific note
Interleave is the stripe unit used to distribute successive logical ranges across disks. Preserve the requested byte value, each disk sector size and any provider granularity for this HRESULT. Do not “fix” the request by rounding silently: the management layer must either choose a documented supported value or report the capability mismatch to its caller for this HRESULT.
Verification after correction
Rebuild the layout from enumerated objects and checked arithmetic rather than patching one serialized field; validate counts, indices, sizes, alignment and overflow before submission for this HRESULT. Apply the change through the supported storage API, then close and reacquire affected objects before retrying while diagnosing it.
- The controlled A/B case changes only the invariant responsible for this HRESULT.
- No unrelated disk, cluster owner, tier policy or virtual-disk backing file is altered to hide it.
- Health, synchronization or job state reaches a terminal value consistent with the repaired the operation.
- Telemetry includes both symbolic names when it or
ERROR_VOLMGR_UNEXPECTED_DISK_LAYOUT_CHANGEoccurs again.
A reboot, blanket disk conversion or deletion of storage metadata is not a justified first response to it; it changes multiple invariants and can erase the evidence needed to identify the defect.
Technical references
- Microsoft: COM error codes for VOLMGR, VHD and SDIAG — documents the supported management path relevant to it.
- Microsoft: Virtual Disk Service object model — defines the volmgr objects used to interpret it.
- Microsoft: Pack object — primary API or object-model reference for the boundary.
- Microsoft: Virtual Disk Service common return codes — use this source to verify volmgr state and parameters for this HRESULT.
Looking for a different code? Search another status or error code.