| Previous | Next |
| ERROR_VOLMGR_VOLUME_NOT_MIRRORED | ERROR_VOLMGR_VOLUME_OFFLINE |
ERROR_VOLMGR_VOLUME_NOT_RETAINED
Identify the owner before touching the layout: volmgr volume not retained
The practical meaning of ERROR_VOLMGR_VOLUME_NOT_RETAINED (0xC038004A) is tied to logical volume geometry and the disk extents that realize it: the volume has no retained partition record to remove, restore or query for it. The result does not, by itself, prove file-system corruption or physical-media failure while diagnosing this result.
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 for it. This object model determines which identifiers, counts and ownership state are meaningful.
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 while diagnosing it.
Minimum diagnostic set
| Storage diagnostic field | Value |
|---|---|
| Rejected invariant | the volume has no retained partition record to remove, restore or query |
| Identity and generation | volume ID, requested length, sector sizes, extent table, plex/member counts, disk health and the exact VM_VOLUME_LAYOUT buffer |
| Narrow experiment | query the retain-partition flag, apply or remove it once on a test volume, and retry the original operation without repartitioning |
| Closest comparison | ERROR_VOLMGR_VOLUME_RETAINED |
| Owning object | logical volume geometry and the disk extents that realize it |
A management layer handling this result should report later recovery errors separately, because they answer a different question from the failed storage operation.
Reproduce without destructive cleanup
- Create a nonproduction case for it that preserves the same geometry and ownership model for it.
- Collect volume ID, requested length, sector sizes, extent table, plex/member counts, disk health and the exact VM_VOLUME_LAYOUT buffer before invoking the first mutating API.
- Change one condition only: query the retain-partition flag, apply or remove it once on a test volume, and retry the original operation without repartitioning.
- Re-enumerate after the transition and confirm this result is not reproduced by a stale handle from the old generation.
Use ERROR_VOLMGR_VOLUME_RETAINED as the nearest comparison. It is specific to the volume has no retained partition record to remove, restore or query; the neighboring result belongs to another validation or lifecycle branch for it. Keeping both names prevents a generic storage label from hiding the actual owner.
Mechanism-specific note
Retain-partition state records whether partition identity should survive deletion of the dynamic volume while diagnosing it. Query the flag and the partition record together. It is not a general “keep data” switch, and toggling it cannot repair missing extents, synchronization failures or an invalid pack log.
Restore the contract
Refresh the disk layout, serialize the change as one volume-manager transaction and reject any external partition mutation until commit or rollback completes. Apply the change through the supported storage API, then close and reacquire affected objects before retrying while diagnosing it.
- the first retry uses newly enumerated identifiers rather than cached handles.
- 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_VOLUME_RETAINEDpath 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. Unsupported edits can turn a recoverable state mismatch into persistent corruption.
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.