| Previous | Next |
| RTC_E_SIP_OTHER_PARTY_JOIN_IN_PROGRESS | RTC_E_PRESENCE_ENABLED |
RTC_E_INVALID_OBJECT_STATE
Where the state changes: RTC_E_INVALID_OBJECT_STATE
This HRESULT is emitted for a defined RTC state rather than an unspecified communications problem; that state is the targeted RTC object is alive but not in a state that permits this method.
At the HRESULT layer, this result appears as 0x80EE0061 in the RTC interface facility 0xEE; preserving the facility and symbol prevents it from being grouped incorrectly with unrelated networking or media errors.
To establish this result, record interface type, object state, owner generation, previous event, and requested transition; this matters because object-state failure is narrower than client-wide initialization or shutdown failure.
Protocol and object state
| RTC area | RTC client lifecycle |
|---|---|
| Condition to prove | the targeted RTC object is alive but not in a state that permits this method |
| Objects to correlate | IRTCClient instance, initialization generation, shutdown state, event sink, platform capability |
| Safe corrective direction | wait for a legal state or discard the stale object if its lifecycle ended |
RTC Client API objects are stateful COM objects; child sessions and profiles belong to the client instance that created them. A shutdown transition invalidates pending operations even if application code still holds interface pointers.
Comparison with adjacent codes
Use “the targeted RTC object is alive but not in a state that permits this method” as the discriminator when comparing the related RTC results below.
RTC_E_MAX_PENDING_OPERATIONS | the RTC client reached its cap on concurrent asynchronous operations |
|---|---|
RTC_E_NOT_ALLOWED | the RTC API contract rejects the action for the current object, role, or configuration |
RTC_E_CLIENT_ALREADY_INITIALIZED | code attempted to initialize an RTC client instance that is already active |
Telemetry and packet evidence
Capture the first result before retry, reconnect, profile re-enable, or teardown changes the evidence; associate this result with one RTC object instance and one transaction or media transition.
- Code-specific proof: record interface type, object state, owner generation, previous event, and requested transition.
- Addressing context: outstanding session/profile count.
- RTC callback state: OS and rtcdll.dll version.
- Transaction boundary: client instance identity.
- Media or profile detail: Initialize and Shutdown call order.
When recording this result, redact credentials, full telephone numbers, private contact lists, and message bodies; retain permitted URI domains, header names, byte counts, hashes, transaction identifiers, timestamps, and state transitions.
Step-by-step isolation
- Start from
0x80EE0061, then find the method/event pair that first exposed it. - Check whether the failure was local before transmission, produced during RTC state validation, or mapped from a remote response.
- the proof step is to record interface type, object state, owner generation, previous event, and requested transition.
- Keep the analysis at the right boundary: object-state failure is narrower than client-wide initialization or shutdown failure.
- After you wait for a legal state or discard the stale object if its lifecycle ended, repeat the smallest reproducer rather than restarting the entire application environment.
Actions that do not address this condition
- Do not reuse child objects after shutdown or reinitialization.
- Do not hide lifecycle bugs by repeatedly constructing new clients inside a retry loop.
- Do not discard the HRESULT facility or state information when converting the result into application telemetry.
Recovery
The owning RTC component should wait for a legal state or discard the stale object if its lifecycle ended; it should also settle or cancel its previous operation before callers begin a replacement.
A retry is safe only after the prior transaction’s outcome is reconciled; reissuing state-changing requests while the peer result is unknown can create contradictory RTC state.
Example: A roaming list object is modified while it is being replaced by a server update.
Verification after a fix
Keep two tests: one that intentionally produces “the targeted RTC object is alive but not in a state that permits this method”, and one that applies the targeted fix; check the callback sequence, 0x80EE0061, final session/profile state, and absence of leaked listeners, dialogs, streams, or registrations.
Technical references
- About the RTC Client API — authoritative context for this result.
- Microsoft RTC return constants — definitions relevant when reproducing it.
Looking for a different code? Search another status or error code.