| Previous | Next |
| ERROR_VOLMGR_TRANSACTION_IN_PROGRESS | ERROR_VOLMGR_VOLUME_CONTAINS_MISSING_DISK |
ERROR_VOLMGR_UNEXPECTED_DISK_LAYOUT_CHANGE
Interpret the state transition: volmgr unexpected disk layout change
Windows returns ERROR_VOLMGR_UNEXPECTED_DISK_LAYOUT_CHANGE, value 0xC0380044, at the volmgr boundary. It means that disk extents or partition metadata changed outside the volume-manager transaction that had captured the layout. Preserve the exact handle and generation of kernel volume-manager layout transaction and VM_VOLUME_LAYOUT input before any rescan changes the evidence.
Record geometry, identity and ownership
| Storage diagnostic field | Value |
|---|---|
| Rejected invariant | disk extents or partition metadata changed outside the volume-manager transaction that had captured the layout |
| 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_STRUCTURE_SIZE_INVALID |
| Owning object | kernel volume-manager layout transaction and VM_VOLUME_LAYOUT input |
When it is followed by a secondary cleanup failure, store both codes with timestamps and retain this one as the initiating result.
Separate validation from capability
- Create a nonproduction case that preserves the same geometry and ownership model.
- 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 this result is not reproduced by a stale handle from the old generation.
Use ERROR_VOLMGR_STRUCTURE_SIZE_INVALID as the nearest comparison. This result is specific to disk extents or partition metadata changed outside the volume-manager transaction that had captured the layout; the neighboring result belongs to another validation or lifecycle branch. Keeping both names prevents a generic storage label from hiding the actual owner.
Mechanism-specific note
Keep the exact storage identity and state transition associated with this HRESULT. A successful rescan does not prove the original operation was valid, because it may have replaced the object instance that failed.
Verification after correction
Refresh the disk layout, serialize the change as one volume-manager transaction and reject any external partition mutation until commit or rollback completes. Keep the correction scoped to the owning object and avoid rewriting adjacent metadata merely to make the call return success.
- The controlled A/B case changes only the invariant that triggers this result.
- 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 operation.
- Telemetry includes both symbolic names when it or
ERROR_VOLMGR_STRUCTURE_SIZE_INVALIDoccurs again.
Technical references
- Microsoft: COM error codes for VOLMGR, VHD and SDIAG — primary API or object-model reference.
- Microsoft: Virtual Disk Service object model — use this source to verify volmgr state and parameters.
- Microsoft: Pack object — documents the supported management path relevant to this HRESULT.
- Microsoft: Virtual Disk Service common return codes — defines the volmgr objects used to interpret it.
Looking for a different code? Search another status or error code.
