What does HRESULT 0x8000000A (E_PENDING) mean?

 
Could be also:
ConstantTypeOS
STATUS_HANDLES_CLOSEDNTSTATUSWindows
Previous Next
EVT_WDSMCS_S_PARAMETERS_READ E_BOUNDS

E_PENDING

Required data is not available yet

E_PENDING is HRESULT 2147483658 (0x8000000A) from winerror.h. AllStat describes it as “The data necessary to complete this operation is not yet available.” In the Windows Runtime metadata, object lifetime, asynchronous operation, activation, and apartment model, the code identifies a specific failure boundary and should not be replaced by a generic COM exception.

Handling E_PENDING correctly requires the code-specific postcondition, not merely the fact that FAILED(hr) is true.

Diagnostic sequence

  • Capture the raw unsigned value 0x8000000A and symbolic name E_PENDING before a language projection, exception wrapper, or generic COM helper replaces it.
  • Identify the exact interface, method, callback, activation request, metadata query, access-control operation, or marshaling boundary that returned E_PENDING.
  • Reconstruct the operation timeline for E_PENDING, including object creation, thread or apartment initialization, security setup, callbacks, mutations, shutdown, and cleanup.
  • Prove the decisive condition: a documented completion signal, callback, event, or subsequent query exists and the caller keeps the producing object alive until it fires.
  • Inspect every output parameter, handle, interface pointer, token, SID, ACL, stream, buffer, server-side object, or asynchronous result produced before E_PENDING.
  • Reproduce E_PENDING with the smallest safe input, change only the suspected precondition, and verify that both the HRESULT and postcondition change as predicted.

Where it is encountered

  • E_PENDING can be returned during C++/WinRT, WRL, .NET projections, or native WinRT ABI calls. For E_PENDING, record the interface, method, component version, thread, apartment, process, and correlation ID.
  • E_PENDING can be returned during runtime-class activation, WinMD reflection, asynchronous objects, observable state, or view lifecycle. For E_PENDING, record the interface, method, component version, thread, apartment, process, and correlation ID.
  • E_PENDING can be returned during cross-thread and cross-apartment handoff between UI, ASTA, STA, MTA, broker, and background work. For E_PENDING, record the interface, method, component version, thread, apartment, process, and correlation ID.

The immediate focus for E_PENDING is an operation that deliberately exposes deferred data or asynchronous production rather than a completed value. Keep E_PENDING 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 a documented completion signal, callback, event, or subsequent query exists and the caller keeps the producing object alive until it fires. If this condition cannot be proven for E_PENDING, stop before consuming outputs or repeating side effects.

For E_PENDING, 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.

Evidence and telemetry

  • Preserve operation identifier and generation for E_PENDING.
  • Preserve completion mechanism and subscription state for E_PENDING.
  • Preserve data item or property requested for E_PENDING.
  • Preserve producer lifetime and cancellation token for E_PENDING.
  • Preserve time from pending result to completion for E_PENDING.

For E_PENDING, also record UTC time, process and thread IDs, apartment type, component version, security or package identity where relevant, and a correlation ID. For E_PENDING, use hashes, lengths, GUIDs, and SID strings rather than logging confidential payloads or credentials.

Difference from nearby HRESULTs

E_PENDING means the result may become available later; E_ABORT means the operation was stopped, while a timeout means the caller stopped waiting without proving completion.

Tests for E_PENDING should force both results and verify that object lifetime, output use, and user messaging differ.

Correct handling and recovery

Keep the operation pending, subscribe once to its completion path, and avoid reading output buffers as final. Cancellation must detach callbacks and release resources without racing the producer.

Repeat the operation after E_PENDING only when the documented precondition, identity, apartment, object generation, buffer, or configuration has changed.

Practical scenario

A thumbnail provider returns <code>E_PENDING</code> while decoding an image. The shell retains the request token, waits for the provider notification, and asks again only after the generation changes.

A regression test should reproduce E_PENDING, assert the raw HRESULT and all relevant outputs, then correct only the decisive condition and verify the intended success or neighboring failure result.

Lifetime, retry, and cleanup rules

After E_PENDING, determine whether the current object, interface pointer, call context, token, stream, metadata reader, asynchronous operation, or access-control instance remains valid. For E_PENDING, 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 E_PENDING should state the trigger, maximum attempts, cancellation owner, and reconciliation step for effects that may have completed elsewhere.

Developer and administrator guidance

A support bundle for E_PENDING should include first-occurrence logs, interface and component identity, object generation, relevant policy, and safe hashes. For E_PENDING, redact credentials, tokens, private metadata, ACL identities, and serialized payload contents.

For E_PENDING, change the smallest component, identity, ACL, package, or threading boundary that the evidence identifies, then reproduce the same operation. Define who owns retry, cancellation, cleanup, policy changes, package repair, and user-facing messaging for E_PENDING.

References


Looking for a different code? Search another status or error code.