| Previous | Next |
| WININET_E_DECODING_FAILED | CO_E_SCM_ERROR |
CO_E_CLASS_CREATE_FAILED
Treat this HRESULT as a marker, not as a request for a generic restart or reinstall. It is returned when COM located an activation route but failed while obtaining or invoking the class factory that creates the requested object.
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. REGDB_E_CLASSNOTREG means no usable registration; CO_E_CLASS_CREATE_FAILED means activation progressed far enough to attempt class-object creation. Compare lifecycle, identity, caller, and first API.
Diagnostic worksheet
| Incident evidence | Question it answers |
|---|---|
| CLSID, requested IID, CLSCTX flags, bitness, and activation machine | Pins evidence to one attempt. |
| InprocServer32 or LocalServer32 registration resolved for that caller | Separates contract failure from environment. |
| Module load/entry-point result or server-side class-factory registration event | Creates a stable before/after control. |
| Server crash, loader error, dependency failure, and the original activation HRESULT | 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
- Activate the same CLSID with a minimal CoCreateInstance client of matching bitness; keep every other input fixed and record the first event that differs from the failing run.
- Call CoGetClassObject separately to isolate class-factory acquisition from instance creation; use a disposable or backed-up environment when the comparison changes boot, security, device, queue, or encryption state.
- Load the registered module with dependency diagnostics in a clean process; retain one negative control so that a broad workaround is not mistaken for a root-cause correction.
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 COM class-factory creation operation with targeted instrumentation before closing the incident.
Nearby states and false leads
Use the outcomes to narrow the layer rather than to accumulate unrelated fixes for COM class-factory creation:
| 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: Repair the class factory, module dependencies, registration view, or server initialization that fails before object construction. Preserve the pre-change configuration or trace.
Close the incident only when CoGetClassObject and instance creation succeed from the intended client architecture, and a missing dependency control reproduces the earlier boundary. Repeat under the original identity and state. A different environment is comparison, not proof.
Technical references
Use these sources for the formal contract, then combine them with evidence from the returning application or service for COM class-factory creation:
- 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.