| Previous | Next |
| CO_E_UNREVOKED_REGISTRATION_ON_APARTMENT_SHUTDOWN | E_ADS_BAD_PATHNAME |
CO_E_PREMATURE_STUB_RUNDOWN
COM stub was rundown while external clients remained
CO_E_PREMATURE_STUB_RUNDOWN is HRESULT 2147500085 (0x80004035) from winerror.h. AllStat describes it as “The object has been rundown by the stub manager while there are external clients.” The value must be interpreted at marshaled object lifetime managed by a stub manager across apartment or process boundaries, because the same high-level symptom can come from a different contract boundary and require different cleanup.
The decisive Interpretation is that the server-side stub was released or disconnected even though external clients still held references. For reliable triage of this result, store the native HRESULT and symbolic identity before generic error handling rewrites either one.
Where the result appears
- This result may surface in marshaled object lifetime managed by a stub manager across apartment or process boundaries.
- 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.
The root-cause boundary for it is the component that returned it, not the application screen on which the result was eventually displayed.
Typical causes and interpretation boundary
Common cause categories for it are: the server calls CoDisconnectObject too early; lifetime bookkeeping is corrupted; shutdown races with clients; custom marshaling violates reference rules. Investigate this result through falsifiable cause hypotheses and keep the first lower-level failure that explains the observed HRESULT.
The check that separates this result from nearby HRESULTs is: the server-side stub was released or disconnected even though external clients still held references. Use the decisive condition for it as a test assertion; if it cannot be asserted, diagnosis is not complete.
Correct handling and recovery
The appropriate recovery is to preserve server objects until documented disconnect conditions, serialize shutdown with proxy lifetime, and investigate reference-count or marshaling bugs. Do not loop on it; retry only under a documented transient condition with bounded delay and post-operation reconciliation.
After observing it, separate local resource cleanup from server-side reconciliation and perform each only for the failing activity ID.
Practical scenario
A service tears down a session object immediately after its local owner releases it, while a remote client still holds a proxy; lifetime is tied to external references instead.
The acceptance test for it should prove that the proposed repair changes the predicted contract fact rather than merely hiding the message.
Difference from related HRESULTs
RPC_E_DISCONNECTED is observed by a caller after disconnection; this code diagnoses premature server-side stub rundown.
Preserve the neighboring-result distinction for it in metrics and incident reports to avoid applying the wrong remediation.
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
- Microsoft: HRESULT values
- Microsoft: common HRESULT values
- Microsoft: COM processes, threads, and apartments
Looking for a different code? Search another status or error code.