| Previous | Next |
| ERROR_VOLMGR_NOT_PRIMARY_PACK | ERROR_VOLMGR_NUMBER_OF_DISKS_IN_PLEX_INVALID |
ERROR_VOLMGR_PACK_LOG_UPDATE_FAILED
Locate the rejected storage invariant: volmgr pack log update failed
The practical meaning of ERROR_VOLMGR_PACK_LOG_UPDATE_FAILED (0xC0380053) is tied to dynamic-disk pack identity, quorum and replicated configuration log: the new pack log record could not be committed to any required disk copy, so the metadata transaction cannot be trusted. 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 while diagnosing this result. Indices and counts are relative to the submitted layout generation, while configuration logs are replicated across participating dynamic disks while diagnosing it. This object model determines which identifiers, counts and ownership state are meaningful while diagnosing 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 new pack log record could not be committed to any required disk copy, so the metadata transaction cannot be trusted |
| 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 | enumerate configuration-log copies and sequence numbers, restore one healthy writable disk in a lab pack, and repeat the commit |
When it is followed by a secondary cleanup failure, store both codes with timestamps and retain this one as the initiating result while diagnosing this result.
One-variable reproduction
- serialize the failing request and the enumeration from which its identifiers came for it.
- 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: enumerate configuration-log copies and sequence numbers, restore one healthy writable disk in a lab pack, and repeat the commit.
- 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 new pack log record could not be committed to any required disk copy, so the metadata transaction cannot be trusted; log the neighboring code separately so capability, identity and state are not conflated.
Mechanism-specific note
Dynamic-disk configuration is replicated, and sequence plus integrity decide which copy is authoritative. Inventory every participating disk and record the newest readable sequence before repair for it. Sector-level edits or copying a log from another pack can destroy the GUID and generation relationships that allow supported recovery to select a consistent configuration.
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. Apply the change through the supported storage API, then close and reacquire affected objects before retrying.
- 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 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.