| Previous | Next |
| RPC_E_INVALID_OBJECT | RPC_S_WAITONTIMER |
RPC_S_CALLPENDING
COM call is still pending
RPC_S_CALLPENDING is HRESULT 2147549461 (0x80010115) from winerror.h. AllStat describes it as “OLE has sent a request and is waiting for a reply.” The value must be interpreted at OLE/COM call control while a request has been sent and the caller is awaiting a reply, because the same high-level symptom can come from a different contract boundary and require different cleanup.
The decisive Interpretation is that the call has not completed and remains outstanding rather than having failed. A diagnostic event for this HRESULT should retain both representations of the HRESULT and the exact API boundary that produced it.
Where the result appears
- This result may surface in OLE/COM call control while a request has been sent and the caller is awaiting a reply.
- The first boundary to preserve for this HRESULT is the exact activation, initialization, call-control, or lifetime step that returned it.
- record whether the failure occurred before an object identity existed, while a method was running, or during shutdown; those phases imply different ownership and retry rules.
Before assigning cause to this result, identify the responsible thread, apartment, process, library generation, and server instance rather than relying on the final dialog text.
Typical causes and interpretation boundary
Common cause categories for this HRESULT are: the server is still processing; the STA must dispatch messages; a nested wait observes the outstanding call; network latency delays reply. The candidate causes for this HRESULT are alternatives, so test one precondition at a time instead of applying several broad repairs together.
The check that separates this result from nearby HRESULTs is: the call has not completed and remains outstanding rather than having failed. When the boundary condition behind it has not been proven, avoid retries or repairs that assume a different neighboring HRESULT.
Correct handling and recovery
The appropriate recovery is to continue through the documented wait or message-pump mechanism, honor cancellation, and avoid issuing a duplicate non-idempotent call. Before retrying this result, specify which precondition changed and how duplicate effects or stale outputs will be detected.
Inspect every output before cleanup because interfaces, buffers, server effects, or metadata handles may be partially initialized.
Practical scenario
A UI STA waits for a document server and receives the pending status while its message loop continues dispatching incoming COM calls.
Test it by reproducing the smallest failing contract, recording postconditions, and then changing a single input or state transition.
Difference from related HRESULTs
RPC_S_WAITONTIMER means COM is deliberately delaying before a retry; it means the original call remains outstanding.
Keeping it separate from its neighbor improves retry, cleanup, and user messaging because the two results imply different postconditions.
Developer and administrator guidance
Code handling it should classify it by lifecycle and ownership rather than by the high bit alone. For <code>it</code>, initialization failures normally require rebuilding the process or thread environment, capability results require a fallback, and uncertain remote outcomes require reconciliation before retry.
Operational dashboards should keep it distinct from generic COM failures and attach deployment, service, package, runtime, policy, and architecture dimensions. Administrators should avoid broad registry edits, blanket firewall changes, or permission expansion unless the captured evidence for this HRESULT identifies that subsystem.
References
- Microsoft: COM error codes
- Microsoft: COM processes, threads, and apartments
- Microsoft: COM security defaults
- Microsoft: HRESULT values
Looking for a different code? Search another status or error code.