| Previous | Next |
| ERROR_VOLMGR_TOO_MANY_NOTIFICATION_REQUESTS | ERROR_VOLMGR_UNEXPECTED_DISK_LAYOUT_CHANGE |
ERROR_VOLMGR_TRANSACTION_IN_PROGRESS
Identify the owner before touching the layout: volmgr transaction in progress
ERROR_VOLMGR_TRANSACTION_IN_PROGRESS (0xC0380043) is emitted by the volmgr path when a metadata transaction currently owns the pack and prevents a second layout mutation from starting. The deciding object is kernel volume-manager layout transaction and VM_VOLUME_LAYOUT input, so the first investigation belongs there rather than in a generic “disk failure” bucket.
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.
Minimum diagnostic set
| Storage diagnostic field | Value |
|---|---|
| Owning object | kernel volume-manager layout transaction and VM_VOLUME_LAYOUT input |
| Rejected invariant | a metadata transaction currently owns the pack and prevents a second layout mutation from starting |
| Identity and generation | pack and volume IDs, input structure version and sizes, transaction ID, disk-layout snapshot before the call and the first kernel storage event |
| Narrow experiment | hold one layout transaction open in a test harness, issue the competing mutation, then retry after an explicit commit or rollback |
| Closest comparison | ERROR_VOLMGR_UNEXPECTED_DISK_LAYOUT_CHANGE |
Do not overwrite this result with a close, detach or rollback error. Preserve the causal order so the original storage contract remains visible.
Reproduce without destructive cleanup
- Before changing state, freeze the failing generation and save pack and volume IDs, input structure version and sizes, transaction ID, disk-layout snapshot before the call and the first kernel storage event.
- Exercise this exact comparison: hold one layout transaction open in a test harness, issue the competing mutation, then retry after an explicit commit or rollback.
- During the 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.
The distinction from ERROR_VOLMGR_UNEXPECTED_DISK_LAYOUT_CHANGE is operational. A metadata transaction currently owns the pack and prevents a second layout mutation from starting; log the neighboring code separately so capability, identity and state are not conflated.
Mechanism-specific note
Keep the exact storage identity and state transition associated with this HRESULT. A successful rescan does not prove the original operation was valid, because it may have replaced the object instance that failed.
Restore the contract
Wait for the owning job or transaction to reach a terminal state, then refresh all identifiers before issuing a single retry. The repair is incomplete until a fresh enumeration and new handle observe the corrected state.
- the first retry uses newly enumerated identifiers rather than cached handles.
- The durable metadata or provider state agrees with the success returned after this result.
- A second run after close/reopen does not recreate the rejected condition.
- the nearby
ERROR_VOLMGR_UNEXPECTED_DISK_LAYOUT_CHANGEpath remains separately testable and separately logged.
Technical references
- Microsoft: COM error codes for VOLMGR, VHD and SDIAG — defines the volmgr objects used to interpret this result.
- Microsoft: Virtual Disk Service object model — primary API or object-model reference.
- Microsoft: Pack object — use this source to verify volmgr state and parameters.
- Microsoft: Virtual Disk Service common return codes — documents the supported management path relevant to this result.
Looking for a different code? Search another status or error code.