| Previous | Next |
| ERROR_VOLMGR_NUMBER_OF_PLEXES_INVALID | ERROR_VOLMGR_PACK_ID_INVALID |
ERROR_VOLMGR_PACK_DUPLICATE
Locate the rejected storage invariant: volmgr pack duplicate
ERROR_VOLMGR_PACK_DUPLICATE (0xC038002F) is emitted by the volmgr path when the source and destination pack identifiers resolve to the same disk group, so the requested cross-pack operation has no distinct target. The deciding object for it is dynamic-disk pack identity, quorum and replicated configuration log, so the first investigation belongs there rather than in a generic “disk failure” bucket.
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 for it.
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.
Evidence to preserve before repair
| Storage diagnostic field | Value |
|---|---|
| Closest comparison | ERROR_VOLMGR_UNEXPECTED_DISK_LAYOUT_CHANGE |
| Owning object | dynamic-disk pack identity, quorum and replicated configuration log |
| Rejected invariant | the source and destination pack identifiers resolve to the same disk group, so the requested cross-pack operation has no distinct target |
| Identity and generation | pack GUID and name, online state, primary flag, disk inventory, configuration-log sequence numbers, quorum view and failing transaction ID |
| 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 |
A management layer handling this result should report later recovery errors separately, because they answer a different question from the failed storage operation.
One-variable reproduction
- serialize the failing request and the enumeration from which its identifiers came.
- Preserve pack GUID and name, online state, primary flag, disk inventory, configuration-log sequence numbers, quorum view and failing transaction ID while every handle is still valid.
- Repeat the operation using this controlled change: 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.
- Close and reacquire the relevant objects, then run once more to test lifecycle correctness after this result.
The distinction from ERROR_VOLMGR_UNEXPECTED_DISK_LAYOUT_CHANGE is operational. The decisive condition is the source and destination pack identifiers resolve to the same disk group, so the requested cross-pack operation has no distinct target; log the neighboring code separately so capability, identity and state are not conflated.
Mechanism-specific note
A cross-pack operation requires two different disk groups while diagnosing this result. Compare the canonical GUIDs after resolving aliases and imported-pack names. Two interface objects can refer to the same pack, especially after refresh or import, so pointer inequality is not evidence that source and destination are distinct.
Repair without rewriting unrelated metadata
Repair the pack configuration through supported dynamic-disk management, preserving GUIDs and the newest valid log sequence; avoid sector-level edits to replicated metadata for it. After correcting it, reopen the pack, volume, tier, snapshot or virtual disk so no cached generation participates in the validation run.
- 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.
- The application still distinguishes it from
ERROR_VOLMGR_UNEXPECTED_DISK_LAYOUT_CHANGEand has no unbounded retry loop.
Do not use it as a reason to edit dynamic-disk sectors, VHDX metadata, RCT sidecars or snapshot support files directly. Unsupported edits can turn a recoverable state mismatch into persistent corruption.
Technical references
- Microsoft: COM error codes for VOLMGR, VHD and SDIAG — defines the volmgr objects used to interpret it.
- Microsoft: Virtual Disk Service object model — primary API or object-model reference for the boundary.
- Microsoft: Pack object — use this source to verify volmgr state and parameters for it.
- Microsoft: Virtual Disk Service common return codes — documents the supported management path relevant to it.
Looking for a different code? Search another status or error code.