| Previous | Next |
| STATUS_NO_UNICODE_TRANSLATION | STATUS_CONTEXT_MISMATCH |
STATUS_ALREADY_REGISTERED
Treat registration as a balanced lifecycle with one clear owner
STATUS_ALREADY_REGISTERED says the callback presented to a registration facility is already registered. This is not normally fixed by registering the same callback again with a new local flag. The important questions are who owns the registration, which identity the subsystem uses to detect duplicates, and whether the corresponding unregister path ran.
Windows exposes many callback-registration lifecycles. ObRegisterCallbacks requires drivers to unregister callbacks before unload. ETW requires a matching EtwUnregister for every successful EtwRegister. Driver-defined callback objects use ExUnregisterCallback when notification is no longer required. The exact duplicate rule varies by API, but all of these interfaces make registration lifetime explicit.
Log the callback address, context, registration handle, provider/object identity, and lifecycle generation. Protect initialization so two threads cannot both observe an unregistered local state and race into registration. Set the local “registered” flag only after the API succeeds, and clear it in the same ownership domain that performs unregistration. If registration survives across a restartable component, do not reuse a stale local handle without confirming the underlying registration still belongs to that generation.
What to inspect
- Find the successful earlier registration and identify the owner responsible for unregistering it.
- Serialize registration state transitions and update local state only after API success.
- Pair every successful registration with the documented unregister routine before unload or teardown.
References
- Microsoft: ObRegisterCallbacks
- Microsoft: EtwRegister
- Microsoft: Using a driver-defined callback object
- Microsoft: PsSetCreateProcessNotifyRoutine
- Microsoft Open Specifications: NTSTATUS values
Looking for a different code? Search another status or error code.