| Previous | Next |
| ERROR_VOLMGR_MIRROR_NOT_SUPPORTED | ERROR_BCD_TOO_MANY_ELEMENTS |
ERROR_VOLMGR_RAID5_NOT_SUPPORTED
Why this is narrower than a generic disk error: volmgr raid5 not supported
ERROR_VOLMGR_RAID5_NOT_SUPPORTED has unsigned value 0xC038005C. In the volmgr layer, it rejects a specific contract because the current product, provider or disk set cannot create or maintain a RAID-5 plex. Diagnosis of this result should follow logical volume geometry and the disk extents that realize it 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. This object model determines which identifiers, counts and ownership state are meaningful.
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.
Storage facts that change the diagnosis
| Storage diagnostic field | Value |
|---|---|
| Narrow experiment | separate plex-type validation from platform capability by testing one real RAID-5 plex and one nonparity plex on the same system |
| Closest comparison | ERROR_VOLMGR_PLEX_NOT_RAID5 |
| Owning object | logical volume geometry and the disk extents that realize it |
| Rejected invariant | the current product, provider or disk set cannot create or maintain a RAID-5 plex |
| 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 |
A management layer handling this result should report later recovery errors separately, because they answer a different question from the failed storage operation.
A/B test for this HRESULT
- Capture the API parameters and object map that led to this result; do not begin with cleanup.
- Build a passing control with the same disks or image copy and preserve pack and volume IDs, input structure version and sizes, transaction ID, disk-layout snapshot before the call and the first kernel storage event while diagnosing it.
- Run the narrow transition described here: separate plex-type validation from platform capability by testing one real RAID-5 plex and one nonparity plex on the same system.
- Compare resulting IDs, counts, health and ownership to prove the caller crossed the result invariant rather than suppressing it.
Use ERROR_VOLMGR_PLEX_NOT_RAID5 as the nearest comparison. It is specific to the current product, provider or disk set cannot create or maintain a RAID-5 plex; the neighboring result belongs to another validation or lifecycle branch. Keeping both names prevents a generic storage label from hiding the actual owner while diagnosing it.
Mechanism-specific note
Separate two questions: whether the selected plex is RAID-5 and whether this Windows edition/provider can perform the requested parity operation. Record the actual plex type, disk count and provider capability so a topology mismatch is not misdiagnosed as a product limitation, or vice versa while diagnosing it.
Corrective action and regression check
Select an operation compatible with the actual plex type and keep at least one active data copy throughout detach, repair or regeneration. The result repair is incomplete until a fresh enumeration and new handle observe the corrected state.
- The original request now reaches success or a documented later status with the intended layout and access mode for it.
- 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 for it.
- The application still distinguishes it from
ERROR_VOLMGR_PLEX_NOT_RAID5and has no unbounded retry loop.
Avoid broad rescans, forced failovers and metadata deletion until identities and generations are captured. Those actions can make a stale request appear to heal without fixing its caller.
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 it.
Looking for a different code? Search another status or error code.