| Previous | Next |
| RTC_E_CLIENT_ALREADY_INITIALIZED | RTC_E_PRESENCE_NOT_ENABLED |
RTC_E_CLIENT_ALREADY_SHUT_DOWN
Protocol boundary: RTC_E_CLIENT_ALREADY_SHUT_DOWN
This result marks a specific boundary in initialization, shutdown, platform support, and global client-object configuration: the RTC client instance has completed shutdown and cannot service the requested operation; treating it as a generic RTC failure loses the state needed to choose a safe next action.
For correlation, retain 0x80EE0027 in the RTC interface facility 0xEE together with this result; for this HRESULT, generic HRESULT text can otherwise hide the protocol family and the exact RTC branch.
Evidence for this HRESULT should show that you record shutdown call stack, pending operations, and age of the interface pointer used afterward; the diagnostic distinction for this HRESULT is that shutdown is irreversible for that instance even if COM references remain.
Protocol and object boundary
| RTC area | RTC client lifecycle boundary |
|---|---|
| Objects to correlate | IRTCClient instance, initialization generation, shutdown state, event sink, platform capability |
| Condition to prove | the RTC client instance has completed shutdown and cannot service the requested operation |
| Safe corrective direction | discard all generation-owned objects and construct a fresh client for future work |
Two RTC rules frame this result: first, RTC Client API objects are stateful COM objects; child sessions and profiles belong to the client generation that created them; second, for this HRESULT, A shutdown transition invalidates pending operations even if application code still holds interface pointers.
How to prove the condition
- At the source of this result, preserve the HRESULT, method or callback, timestamp, thread/task correlation, and object generation.
- reconstruct the immediately preceding RTC transition instead of beginning with the later disconnect or UI notification.
- use protocol and object evidence to record shutdown call stack, pending operations, and age of the interface pointer used afterward.
- confirm the distinction that shutdown is irreversible for that instance even if COM references remain.
- create a fresh operation generation after you discard all generation-owned objects and construct a fresh client for future work, and compare its final state with the failing run.
Correlate wire data and RTC events for this HRESULT; for this HRESULT, either source alone can misclassify local validation as remote rejection, or a remote status as a local media or profile failure.
Minimum incident record
The earliest callback or return site is the most valuable; later it cleanup can replace the original state, so correlate the code with the object generation that produced it.
- Code-specific proof for this HRESULT: record shutdown call stack, pending operations, and age of the interface pointer used afterward.
- Owning object for this HRESULT: OS and rtcdll.dll version.
- Wire evidence for this HRESULT: client instance identity.
- Lifecycle generation for this HRESULT: Initialize and Shutdown call order.
For privacy-safe analysis of it, preserve protocol structure rather than payload content; for this HRESULT, authentication values, complete addresses, buddy lists, and bodies should be redacted or hashed under policy.
Actions that do not address this condition
- The following shortcut is unsafe for this HRESULT: do not reuse child objects after shutdown or reinitialization.
- Another non-solution for this HRESULT is to do not hide lifecycle bugs by repeatedly constructing new clients inside a retry loop.
- Do not translate it into a broad “connection failed” label before preserving the RTC symbol and producing phase.
Correct application response
The owning RTC component should discard all generation-owned objects and construct a fresh client for future work; for this HRESULT, it should also settle or cancel its previous operation before callers begin a replacement.
Do not turn it into an immediate unconditional retry; for this HRESULT, first determine whether the peer could have accepted the prior request and whether RTC still owns a live transaction.
Example for this HRESULT: A reconnect timer fires after the application has already shut down RTC.
Nearby failure modes
It is tied to the condition “the RTC client instance has completed shutdown and cannot service the requested operation”; preserve that producing boundary before choosing recovery; for this HRESULT, the neighboring results below require different control-flow decisions.
RTC_E_INVALID_OBJECT_STATE | the targeted RTC object is alive but not in a state that permits this method |
|---|---|
RTC_E_CLIENT_ALREADY_INITIALIZED | code attempted to initialize an RTC client instance that is already active |
RTC_E_PLATFORM_NOT_SUPPORTED | the installed Windows/RTC platform does not implement the requested API capability |
Facility equality is not semantic equality; route each contrasted value through its own recovery branch.
Verification after a fix
A useful it regression does more than expect an exception; the result test constructs “the RTC client instance has completed shutdown and cannot service the requested operation”, checks the exact HRESULT at the producing RTC boundary, and verifies state ownership before and after the targeted correction.
Technical references
- About the RTC Client API — definitions relevant when reproducing it.
- Microsoft RTC return constants — API or protocol rules used to interpret it.
Looking for a different code? Search another status or error code.