| Previous | Next |
| CO_E_SCM_RPC_FAILURE | CO_E_SERVER_EXEC_FAILURE |
CO_E_BAD_PATH
This code places the first failure in registered COM server path resolution. Operationally, the activation metadata points to a malformed, unavailable, or contextually unusable object/server path.
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. CO_E_SERVER_EXEC_FAILURE means the server command was reached but did not establish COM service; CO_E_BAD_PATH points earlier to path resolution. Compare lifecycle, identity, caller, and first API.
Diagnostic worksheet
| Record | How it narrows the cause |
|---|---|
| The resolved LocalServer32, service, surrogate, or moniker path exactly as COM reads it | Pins evidence to one attempt. |
| Environment expansion, quotes, working directory assumptions, drive mappings, and UNC accessibility | Separates contract failure from environment. |
| Caller/server bitness and the registry view containing the path | Creates a stable before/after control. |
| File existence, signature, ACL, and loader access under the activation identity | Tests whether the first boundary moves. |
Identifiers, timestamps, versions, counts, state flags, hashes, and redacted paths normally provide enough correlation. Keep credentials, private keys, message bodies, recovery material, and personal data out of routine incident logs.
Reproduce the boundary safely
- Launch the registered command line under the configured identity without changing its quoting; retain one negative control so that a broad workaround is not mistaken for a root-cause correction.
- Replace a mapped drive with the equivalent stable local or UNC path in a test registration; keep every other input fixed and record the first event that differs from the failing run.
- Compare registry views from 32-bit and 64-bit clients; use a disposable or backed-up environment when the comparison changes boot, security, device, queue, or encryption state.
If the failure disappears after a broad restart, treat that as a clue about lifetime or state, not as proof of repair. Reproduce the original operation with targeted instrumentation before closing the incident.
Nearby states and false leads
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. |
Closing the incident
Apply the smallest change that addresses the first rejected condition: Store a fully qualified, correctly quoted, identity-accessible path and avoid per-user drive mappings in machine-wide activation metadata. Preserve the pre-change configuration or trace.
Close the incident only when a cold activation resolves the same path from every supported client bitness and survives reboot without environment-dependent lookup. Repeat under the original identity and state. A different environment is comparison, not proof.
Technical references
The diagnostic boundaries above are grounded in the following Microsoft specifications and API documentation:
- 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.