| Previous | Next |
| CO_E_BAD_PATH | CO_E_OBJSRV_RPC_FAILURE |
CO_E_SERVER_EXEC_FAILURE
CO_E_SERVER_EXEC_FAILURE — 0x80080005
A productive investigation starts at out-of-process COM server startup. The status means that the SCM launched or attempted to launch the registered server, but the process did not register its class objects or terminated before activation completed.
Where the failure sits
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 bad path prevents reliable process launch; server execution failure means startup was attempted but the COM handshake did not complete. Compare lifecycle, identity, caller, and first API.
Facts to collect first
| Record | How it narrows the cause |
|---|---|
| Registered executable/service command, AppID, identity, and activation timeout | Tests whether the first boundary moves. |
| Process creation result, exit code, crash dump, loader events, and command-line arguments | Pins evidence to one attempt. |
| CoRegisterClassObject timing and whether the server message loop remains alive | Separates contract failure from environment. |
| Service dependencies, profile access, desktop interaction assumptions, and side-by-side/runtime dependencies | Creates a stable before/after control. |
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.
Change one variable at a time
- Start the server manually under its configured identity and observe its earliest failure; use a disposable or backed-up environment when the comparison changes boot, security, device, queue, or encryption state.
- Instrument the interval from process creation to CoRegisterClassObject; retain one negative control so that a broad workaround is not mistaken for a root-cause correction.
- Use a minimal server configuration to separate startup dependencies from COM registration; keep every other input fixed and record the first event that differs from the failing run.
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.
What the result does not prove
Interpret the controlled tests as evidence about the returning boundary:
| 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 | this boundary moved; diagnose the new status separately rather than treating it as confirmation that the entire operation is fixed. |
Verification after correction
Apply the smallest change that addresses the first rejected condition: Fix the server’s early initialization, identity/profile dependency, class registration timing, or crash rather than increasing the activation timeout blindly. Preserve the pre-change configuration or trace.
Close the incident only when repeated cold activations start one healthy server, register the expected CLSID promptly, and survive concurrent client requests. 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.