| Previous | Next |
| RTC_E_MEDIA_AEC | RTC_E_CLIENT_ALREADY_INITIALIZED |
RTC_E_CLIENT_NOT_INITIALIZED
What the RTC value marks: RTC_E_CLIENT_NOT_INITIALIZED
This result belongs to the RTC client lifecycle boundary area of RTC and identifies an RTC method was called before the client completed initialization.
This result carries 0x80EE0025 in the RTC interface facility 0xEE; store the result value at the first RTC callback or method boundary, before retry logic replaces it with a broader timeout or connection message.
Collect enough state to record object construction, Initialize result, event-filter setup, and calling thread order; the result evidence should demonstrate why a valid COM pointer does not imply the RTC client state machine is initialized.
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 | an RTC method was called before the client completed initialization |
| Safe corrective direction | initialize once, verify success, then create child objects and enable profiles |
RTC Client API objects are stateful COM objects; child sessions and profiles belong to the client generation that created them; the second rule relevant to this result is that A shutdown transition invalidates pending operations even if application code still holds interface pointers.
Evidence that separates the cause
Capture the first result before retry, reconnect, profile re-enable, or teardown changes the evidence; associate this result with one RTC object generation and one transaction or media transition.
- Code-specific proof for this HRESULT: record object construction, Initialize result, event-filter setup, and calling thread order.
- Identity and target for this HRESULT: Initialize and Shutdown call order.
- State at production for this HRESULT: thread/apartment and event sink.
- Timing and ordering for this HRESULT: outstanding session/profile count.
Sanitize the result evidence before storage: secrets and user content should disappear, while framing, domains, sizes, hashes, timing, and object-state changes remain available for reproduction.
A safe diagnostic sequence
- Start from
0x80EE0025and it, then find the method/event pair that first exposed it. - the proof step is to record object construction, Initialize result, event-filter setup, and calling thread order.
- check whether the failure was local before transmission, produced during RTC state validation, or mapped from a remote response.
- keep the analysis at the right boundary: a valid COM pointer does not imply the RTC client state machine is initialized.
- after you initialize once, verify success, then create child objects and enable profiles, repeat the smallest reproducer rather than restarting the entire application environment.
The result diagnosis is strongest when object state and protocol trace share timestamps and transaction identifiers; when diagnosing it, avoid treating packet capture and HRESULT logging as substitutes for one another.
How to handle the result
The corrective direction for this HRESULT is to initialize once, verify success, then create child objects and enable profiles; for this HRESULT, cancellation, cleanup, and retry should remain with the component that owns the failed transition.
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 worker thread calls CreateSession before the UI thread finishes initializing RTC.
Actions that do not address this condition
- With it, do not hide lifecycle bugs by repeatedly constructing new clients inside a retry loop.
- Do not reuse child objects after shutdown or reinitialization.
- Do not discard the result facility and state boundary when converting the result into application telemetry.
Related RTC results
Use the following contrast when classifying it: it is tied to the condition “an RTC method was called before the client completed initialization”; preserve that producing boundary before choosing recovery; for this HRESULT, similar subsystem names do not imply identical recovery.
RTC_E_CLIENT_ALREADY_SHUT_DOWN | the RTC client instance has completed shutdown and cannot service the requested operation |
|---|---|
RTC_E_INVALID_OBJECT_STATE | the targeted RTC object is alive but not in a state that permits this method |
RTC_E_MAX_PENDING_OPERATIONS | the RTC client reached its cap on concurrent asynchronous operations |
Telemetry for this HRESULT should retain these distinctions even when several outcomes share HRESULT severity.
Verification after a fix
Keep two tests: one that intentionally produces “an RTC method was called before the client completed initialization”, and one that applies the narrow correction; for this HRESULT, check the callback sequence, 0x80EE0025, final session/profile state, and absence of leaked listeners, dialogs, streams, or registrations.
Technical references
- About the RTC Client API — API or protocol rules used to interpret it.
- Microsoft RTC return constants — authoritative context for the boundary.
Looking for a different code? Search another status or error code.