| Previous | Next |
| CO_E_MALFORMED_SPN | CO_E_PREMATURE_STUB_RUNDOWN |
CO_E_UNREVOKED_REGISTRATION_ON_APARTMENT_SHUTDOWN
Apartment shut down with a COM registration still active
CO_E_UNREVOKED_REGISTRATION_ON_APARTMENT_SHUTDOWN is HRESULT 2147500084 (0x80004034) from winerror.h. AllStat describes it as “The caller failed to revoke a per-apartment registration before apartment shutdown.” The value must be interpreted at per-apartment class, callback, or interface registration tied to apartment lifetime, because the same high-level symptom can come from a different contract boundary and require different cleanup.
The decisive Interpretation is that the apartment began shutdown before the owner revoked a registration that must not outlive it. Treat this result as a contract result from its owning subsystem and retain the unmodified HRESULT in logs and test assertions.
Where the result appears
- This result may surface in per-apartment class, callback, or interface registration tied to apartment lifetime.
- The first boundary to preserve for it 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.
Map this result to one concrete invocation and one concrete object or metadata identity before interpreting the human-readable description.
Typical causes and interpretation boundary
Common cause categories for it are: cleanup was skipped on an exception; ownership moved across threads; the apartment exits while callbacks remain registered. The evidence should distinguish configuration, lifetime, input, identity, resource, and version failures rather than grouping them.
The check that separates this result from nearby HRESULTs is: the apartment began shutdown before the owner revoked a registration that must not outlive it. The text of it narrows the search, but the owning API state must confirm the condition before automation changes the system.
Correct handling and recovery
The appropriate recovery is to store the registration cookie with apartment-owned state, revoke it before CoUninitialize, stop callbacks first, and make teardown idempotent. Recovery from it should name the component responsible for retry and the evidence that makes another attempt safe.
The failure path for it should leave outputs in a known state and avoid double release, double commit, or reuse of stale pointers.
Practical scenario
A UI extension registers a per-apartment handler but closes the window without revoking it; teardown is updated to revoke before apartment shutdown.
To prevent recurrence of it, preserve a minimal fixture that asserts both the failing condition and the state after recovery.
Difference from related HRESULTs
CO_E_PREMATURE_STUB_RUNDOWN concerns remote object lifetime after clients exist; this code concerns a registration left active by its owner.
Classify it by the stated contract difference, since severity bits alone do not determine the correct response.
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 it identifies that subsystem.
References
Looking for a different code? Search another status or error code.