| Previous | Next |
| RTC_E_INVALID_PREFERENCE_LIST | RTC_E_TOO_MANY_RETRIES |
RTC_E_MAX_PENDING_OPERATIONS
Where the state changes: RTC_E_MAX_PENDING_OPERATIONS
This HRESULT is emitted for a defined RTC state rather than an unspecified communications problem; that state is the RTC client reached its cap on concurrent asynchronous operations.
At the HRESULT layer, this result appears as 0x80EE005A 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, enumerate operation types, ages, owners, completion callbacks, and cancellation state; this matters because this is backpressure caused by pending work, not a general thread or memory shortage.
Protocol and object state
| RTC area | RTC client lifecycle |
|---|---|
| Condition to prove | the RTC client reached its cap on concurrent asynchronous operations |
| Objects to correlate | IRTCClient instance, initialization generation, shutdown state, event sink, platform capability |
| Safe corrective direction | stop producing work, complete/cancel abandoned operations, and add bounded queues |
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
RTC_E_NOT_ALLOWED | the RTC API contract rejects the action for the current object, role, or configuration |
|---|---|
RTC_E_CLIENT_NOT_INITIALIZED | an RTC method was called before the client completed initialization |
RTC_E_CLIENT_ALREADY_SHUT_DOWN | the RTC client instance has completed shutdown and cannot service the requested operation |
Telemetry and packet evidence
Before automatic recovery runs, record one client, profile, or session instance and the exact signaling, presence, or media transition in progress.
- Code-specific proof: enumerate operation types, ages, owners, completion callbacks, and cancellation state.
- Addressing context: thread/apartment and event sink.
- RTC callback state: outstanding session/profile count.
- Transaction boundary: OS and rtcdll.dll version.
- Media or profile detail: client instance identity.
Step-by-step isolation
- Use protocol and object evidence to enumerate operation types, ages, owners, completion callbacks, and cancellation state.
- Confirm the distinction that this is backpressure caused by pending work, not a general thread or memory shortage.
- Start a fresh operation after you stop producing work, complete/cancel abandoned operations, and add bounded queues, and compare its final state with the failing run.
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.
Recovery
The appropriate response to it is not a blanket reconnect. Instead, stop producing work, complete/cancel abandoned operations, and add bounded queues, while preserving ownership of cleanup and any bounded retry.
Example: A presence importer sends hundreds of list mutations without waiting for completion events.
Technical references
Looking for a different code? Search another status or error code.