| Previous | Next |
| RPC_E_CANTCALLOUT_ININPUTSYNCCALL | RPC_E_THREAD_NOT_INIT |
RPC_E_WRONG_THREAD
COM interface was used from the wrong thread
RPC_E_WRONG_THREAD is HRESULT 2147549454 (0x8001010E) from winerror.h. AllStat describes it as “The application called an interface that was marshalled for a different thread.” In the COM/RPC call control, message filtering, apartment routing, marshaling, security negotiation, or remote object lifetime, the code identifies a specific failure boundary and should not be replaced by a generic COM exception.
Telemetry should preserve this result as a separate outcome rather than merging it with unrelated COM or WinRT failures.
Where it is encountered
- Cross-apartment or cross-process COM method invocation and activation. Record the interface, method, component version, thread, apartment, process, and correlation ID.
- STA message filtering, reentrancy, call cancellation, timeout, or retry handling.
- DCOM security initialization, proxy/stub marshaling, OBJREF processing, and server object lifetime.
The immediate focus for this HRESULT is an apartment-bound interface pointer invoked from a thread or apartment other than the one for which it was marshaled. Keep it attached to that operation; the same numeric severity outside the owning API does not supply enough context.
Decisive interpretation boundary
Before choosing recovery, verify that originating thread, current thread, apartment model, marshaling mechanism, and object agility are known. If this condition cannot be proven for this HRESULT, stop before consuming outputs or repeating side effects.
Also confirm that all observed objects, tokens, buffers, proxies, metadata files, or ACLs belong to the current operation generation and were not retained from an earlier attempt.
Correct handling and recovery
Marshal the interface, use an agile reference when supported, or dispatch the call to the owning apartment. Never share a raw apartment-bound pointer globally.
Repeat the operation after it only when the documented precondition, identity, apartment, object generation, buffer, or configuration has changed.
Lifetime, retry, and cleanup rules
After it, determine whether the current object, interface pointer, call context, token, stream, metadata reader, asynchronous operation, or access-control instance remains valid. Release only resources owned by the failing attempt, cancel callbacks through their documented mechanism, and avoid double close, double commit, repeated activation, or replay of a non-idempotent remote method.
The retry policy for this HRESULT should state the trigger, maximum attempts, cancellation owner, and reconciliation step for effects that may have completed elsewhere.
Difference from nearby HRESULTs
It concerns use of an existing interface; RO_E_UNSUPPORTED_FROM_MTA concerns activation of an STA-only class from the MTA.
A support tool discussing it should name the neighboring result only after the originating API and decisive state are known.
Practical scenario
A worker thread calls a UI COM object captured on the main STA. The code marshals the interface or posts work to the UI dispatcher.
A regression test should reproduce it, assert the raw HRESULT and all relevant outputs, then correct only the decisive condition and verify the intended success or neighboring failure result.
References
- Microsoft: COM RPC error codes
- Microsoft: IMessageFilter
- Microsoft: RetryRejectedCall
- Microsoft: CoInitialize
- Microsoft: CoInitializeSecurity
- Microsoft: marshaling rules
- Microsoft: HRESULT values
Looking for a different code? Search another status or error code.