| Previous | Next |
| ERROR_VOLMGR_PACK_OFFLINE | ERROR_VOLMGR_PACK_WITHOUT_QUORUM |
ERROR_VOLMGR_PACK_HAS_QUORUM
Identify the owner before touching the layout: volmgr pack has quorum
ERROR_VOLMGR_PACK_HAS_QUORUM (0xC0380034) is emitted by the volmgr path when the disk group already has enough healthy configuration copies, so quorum recovery is not applicable while diagnosing this result. 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.
Keep the first result attached to its request parameters and object generation. Cleanup failures or a later drive-letter change are secondary evidence, not replacements for the original boundary.
Minimum diagnostic set
| Storage diagnostic field | Value |
|---|---|
| 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_NO_VALID_LOG_COPIES |
| Owning object | dynamic-disk pack identity, quorum and replicated configuration log |
| Rejected invariant | the disk group already has enough healthy configuration copies, so quorum recovery is not applicable |
| Identity and generation | pack GUID and name, online state, primary flag, disk inventory, configuration-log sequence numbers, quorum view and failing transaction ID |
Keep this HRESULT as the primary result if rollback or cleanup reports another code; those later values describe recovery, not the first rejected invariant.
Reproduce without destructive cleanup
- 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 GUID and name, online state, primary flag, disk inventory, configuration-log sequence numbers, quorum view and failing transaction ID.
- Run the narrow transition described here: 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 this result.
- Compare resulting IDs, counts, health and ownership to prove the caller crossed the result invariant rather than suppressing it.
Use ERROR_VOLMGR_NO_VALID_LOG_COPIES as the nearest comparison. This result is specific to the disk group already has enough healthy configuration copies, so quorum recovery is not applicable; the neighboring result belongs to another validation or lifecycle branch while diagnosing it. Keeping both names prevents a generic storage label from hiding the actual owner.
Mechanism-specific note
Quorum recovery is intended for a pack that lacks enough mutually consistent configuration copies. If quorum already exists, the safer action is normal reconciliation or repair of the outlier disk while diagnosing it. Record which copies agree on the highest sequence so a “healthy quorum” result is not confused with every disk being healthy.
Restore the contract
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 first retry uses newly enumerated identifiers rather than cached handles while diagnosing it.
- The durable metadata or provider state agrees with the success returned after it.
- A second run after close/reopen does not recreate the rejected the condition.
- the nearby
ERROR_VOLMGR_NO_VALID_LOG_COPIESpath remains separately testable and separately logged.
Do not use it as a reason to edit dynamic-disk sectors, VHDX metadata, RCT sidecars or snapshot support files directly while diagnosing it. 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.