| Previous | Next |
| ERROR_VOLMGR_NUMBER_OF_DISKS_INVALID | ERROR_VOLMGR_RAID5_NOT_SUPPORTED |
ERROR_VOLMGR_MIRROR_NOT_SUPPORTED
What this result says about the disk model: volmgr mirror not supported
The practical meaning of ERROR_VOLMGR_MIRROR_NOT_SUPPORTED (0xC038005B) is tied to logical volume geometry and the disk extents that realize it: the current product, provider or disk layout cannot create or maintain mirrored plexes for it. 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.
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 for it.
Capture the exact object generation
| Storage diagnostic field | Value |
|---|---|
| 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 | logical volume geometry and the disk extents that realize it |
| Rejected invariant | the current product, provider or disk layout cannot create or maintain mirrored plexes |
Do not overwrite this result with a close, detach or rollback error. Preserve the causal order so the original storage contract remains visible.
Prove the boundary in a test volume
- Associate this result with one caller, one transaction and one target UniqueId.
- Save the pre-call and post-call inventories, including pack and volume IDs, input structure version and sizes, transaction ID, disk-layout snapshot before the call and the first kernel storage event.
- Use this A/B case for it 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 it.
The distinction from ERROR_VOLMGR_UNEXPECTED_DISK_LAYOUT_CHANGE is operational. The decisive condition is the current product, provider or disk layout cannot create or maintain mirrored plexes; log the neighboring code separately so capability, identity and state are not conflated for it.
Mechanism-specific note
Capability depends on product edition, provider and the selected disk set while diagnosing it. Record the provider and intended disk geometry before assuming a transient failure. A platform capability result is different from selecting a nonmirrored plex for a mirror-only operation, and the remediation should not conflate those cases.
Safe recovery path
Select an operation compatible with the actual plex type and keep at least one active data copy throughout detach, repair or regeneration. Apply the change through the supported storage API, then close and reacquire affected objects before retrying for it.
- The controlled A/B case changes only the invariant responsible for it.
- 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 for it.
Technical references
- Microsoft: COM error codes for VOLMGR, VHD and SDIAG — use this source to verify volmgr state and parameters for it.
- 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.