| Previous | Next |
| MK_E_NO_NORMALIZED | MEM_E_INVALID_ROOT |
CO_E_SERVER_STOPPING
The important question is not merely what the text says, but which contract was being evaluated. At this boundary, the SCM contacted a registered server while that server was revoking class objects or otherwise stopping.
The contract behind the HRESULT
COM activation is a sequence rather than a single operation: registration lookup, SCM or surrogate selection, process startup, class-factory publication, marshaling, and finally the requested interface call. The useful evidence is the evidence from the first stage that fails; a later RPC or cleanup message can otherwise hide the original activation problem.
Do not collapse this result into a nearby status. A permanently unregistered class differs from a transient server generation that is deliberately stopping. Compare lifecycle, identity, caller, and first API.
Diagnostic worksheet
| Record | How it narrows the cause |
|---|---|
| Server shutdown trigger, service-control event, process lifetime, and outstanding client count | Creates a stable before/after control. |
| CoRevokeClassObject timing and class-factory registration state | Tests whether the first boundary moves. |
| Activation timestamp relative to deployment, recycle, idle shutdown, or crash recovery | Pins evidence to one attempt. |
| Client retry policy and whether it targets the same server generation | Separates contract failure from environment. |
The goal is reproducibility, not a full data dump. Prefer object IDs, configuration exports, event correlation, and redacted paths over credentials, cryptographic material, or user content.
Reproduce the boundary safely
- Block new work before revoking class objects and observe whether activations drain cleanly; retain one negative control so that a broad workaround is not mistaken for a root-cause correction.
- Delay shutdown until outstanding calls finish in a controlled build; keep every other input fixed and record the first event that differs from the failing run.
- Retry once against a new server generation and verify that stale proxies are not reused; use a disposable or backed-up environment when the comparison changes boot, security, device, queue, or encryption state.
Do not use repeated retries as the primary test. In this case, a successful later attempt may reflect a new object, refreshed policy, restarted service, different token, or completed background transition, so record exactly what changed between attempts.
Nearby states and false leads
The following decision points keep the investigation tied to the returning operation:
| Observed result | Interpretation |
|---|---|
| The minimal or known-good comparison succeeds | The control works; inspect production-specific state. |
| The control fails at the same first operation | The control also fails; inspect host/provider evidence. |
| A new HRESULT marks another boundary | The failure moved to another boundary; diagnose the new status separately rather than treating it as confirmation that the entire operation is fixed. |
Closing the incident
The corrective action should be narrow: Coordinate admission control, class-object revocation, outstanding calls, and service stop so clients receive a stable handoff. Preserve the pre-change configuration or trace.
Close the incident only when rolling restart tests show no activation window where clients bind to the retiring generation, and bounded retry reaches the replacement server. Repeat under the original identity and state. A different environment is comparison, not proof.
Technical references
These references define the HRESULT family and subsystem contract used above:
- Microsoft Open Specifications: HRESULT values.
- Microsoft: COM clients and servers.
- Microsoft: CoGetClassObject.
- Microsoft: COM elevation moniker.
Looking for a different code? Search another status or error code.