| Previous | Next |
| STATUS_SERVER_DISABLED | STATUS_TOO_MANY_GUIDS_REQUESTED |
STATUS_SERVER_NOT_DISABLED
The requested state transition is redundant or out of sequence
STATUS_SERVER_NOT_DISABLED is the counterpart to the disabled-server state: the GUID allocation server is already enabled when a caller performs an operation that expects it to be disabled. The diagnostic question is therefore which state transition was attempted and by whom.
Current RPC UUID APIs focus on creating and comparing UUID values; they do not expose this old allocator-state contract as a normal application control surface. That matters when modern code encounters the NTSTATUS through a lower-level compatibility or protocol path. Do not map it to “UUID creation failed” without the native call-site information because the identifier value might never have been generated or examined.
Trace the enable/disable operation, process or service identity, and prior successful transition. Repeated enable operations can indicate duplicated initialization, race-prone ownership, or stale recovery logic. The safe fix is to make allocator lifecycle idempotent where the actual subsystem contract allows it, or serialize the owner’s state transition. Replacing UUIDs does not address the problem.
What to inspect
- Log the attempted allocator transition and current state.
- Look for duplicated initialization after service recovery or failover.
- Keep UUID value validation separate from allocator lifecycle diagnostics.
References
- Microsoft Open Specifications: NTSTATUS values
- Microsoft: UuidCreate
- Microsoft: UuidCompare
- RFC 9562: UUIDs
- Microsoft: Using NTSTATUS values
Looking for a different code? Search another status or error code.