| Previous | Next |
| ERROR_VOLMGR_PLEX_IN_SYNC | ERROR_VOLMGR_PLEX_INDEX_INVALID |
ERROR_VOLMGR_PLEX_INDEX_DUPLICATE
Locate the rejected storage invariant: volmgr plex index duplicate
The practical meaning of ERROR_VOLMGR_PLEX_INDEX_DUPLICATE (0xC0380039) is tied to volume plex descriptor, layout type and regeneration state: the volume layout assigns the same plex ordinal to more than one plex descriptor. The result does not, by itself, prove file-system corruption or physical-media failure.
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 for it. 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.
A useful record contains more than the final UI symptom: retain the first failing call, target identity, topology and state transition before management software rescans the disks.
Evidence to preserve before repair
| Storage diagnostic field | Value |
|---|---|
| Owning object | volume plex descriptor, layout type and regeneration state |
| Rejected invariant | the volume layout assigns the same plex ordinal to more than one plex descriptor |
| Identity and generation | volume ID, plex ordinal, plex type, member array, active/inactive state, health status and current regeneration job |
| Narrow experiment | submit a copied layout with one deliberately repeated ordinal, then change only that ordinal to a unique value |
| Closest comparison | ERROR_VOLMGR_PLEX_INDEX_INVALID |
Do not overwrite this result with a close, detach or rollback error. Preserve the causal order so the original storage contract remains visible.
One-variable reproduction
- Before changing state for it, freeze the failing generation and save volume ID, plex ordinal, plex type, member array, active/inactive state, health status and current regeneration job.
- Exercise this exact comparison for it: submit a copied layout with one deliberately repeated ordinal, then change only that ordinal to a unique value while diagnosing this result.
- During the result comparison, keep image bytes, unrelated disks, provider policy and cluster topology fixed.
- After the test, record the next return value and the durable object state; crossing the boundary should expose a later result rather than silently retrying.
Compare traces for ERROR_VOLMGR_PLEX_INDEX_INVALID and this result. The latter page covers a nearby storage boundary, whereas it rejects the volume layout assigns the same plex ordinal to more than one plex descriptor. A correct caller should be able to reproduce each case independently.
Mechanism-specific note
This code is about uniqueness inside one serialized array, not about the physical health of the indexed object. Dump the full ordinal sequence in submission order and identify which two descriptors claim the same slot for it. Renumbering after filtering or sorting is a common source of this defect because references retained from the prefiltered layout no longer match the emitted array.
Repair without rewriting unrelated metadata
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 it. Keep the correction scoped to the owning object and avoid rewriting adjacent metadata merely to make the call return success.
- 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 while diagnosing it.
- The application still distinguishes it from
ERROR_VOLMGR_PLEX_INDEX_INVALIDand 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 — 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.