| Previous | Next |
| ERROR_VOLMGR_INTERLEAVE_LENGTH_INVALID | ERROR_VOLMGR_MEMBER_IN_SYNC |
ERROR_VOLMGR_MAXIMUM_REGISTERED_USERS
Locate the rejected storage invariant: volmgr maximum registered users
ERROR_VOLMGR_MAXIMUM_REGISTERED_USERS (0xC0380022) is emitted by the volmgr path when the kernel volume manager has exhausted its notification-registration slots for this control interface. The deciding object for it is volume-manager notification registration and pending wait request, 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.
The standard message identifies the immediate condition, but this result also requires the producer API, object topology and attempted state transition while diagnosing it. Capture them before an automatic refresh advances the storage generation for it.
Evidence to preserve before repair
| Storage diagnostic field | Value |
|---|---|
| Identity and generation | registration ID, task number, pending IRP count, process lifetime, pack ID and the notification generation returned before the failure |
| Narrow experiment | register one consumer, issue exactly one asynchronous wait, complete or cancel it, and compare registration/task identifiers at each step |
| Closest comparison | ERROR_VOLMGR_TOO_MANY_NOTIFICATION_REQUESTS |
| Owning object | volume-manager notification registration and pending wait request |
| Rejected invariant | the kernel volume manager has exhausted its notification-registration slots for this control interface |
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
- Associate this result with one caller, one transaction and one target UniqueId.
- Save the pre-call and post-call inventories, including registration ID, task number, pending IRP count, process lifetime, pack ID and the notification generation returned before the failure.
- Use this A/B case for it without touching unrelated storage: register one consumer, issue exactly one asynchronous wait, complete or cancel it, and compare registration/task identifiers at each step.
- Validate both the HRESULT and the on-disk or provider state after the relevant reopen, remount or attach cycle for it.
The distinction from ERROR_VOLMGR_TOO_MANY_NOTIFICATION_REQUESTS is operational. The decisive condition is the kernel volume manager has exhausted its notification-registration slots for this control interface; log the neighboring code separately so capability, identity and state are not conflated.
Mechanism-specific note
Notification registrations have two lifetimes: the registration itself and any outstanding asynchronous wait while diagnosing this result. Log both identifiers and the cancellation path. A service restart, handle close or notification reset can invalidate the old generation even when the numeric task value is later reused, so never match completion by task number alone.
Repair without rewriting unrelated metadata
Repair notification ownership and sequencing: cancel stale waits, unregister only live IDs, then create one replacement registration after the previous generation is closed. 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 for it.
- 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 while diagnosing it.
- The application still distinguishes it from
ERROR_VOLMGR_TOO_MANY_NOTIFICATION_REQUESTSand has no unbounded retry loop.
Avoid broad rescans, forced failovers and metadata deletion until identities and generations are captured. Those actions can make a stale request appear to heal without fixing its caller.
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.