| Previous | Next |
| CO_E_ALREADYINITIALIZED | CO_E_CLASSSTRING |
CO_E_CANTDETERMINECLASS
Class of object cannot be determined
CO_E_CANTDETERMINECLASS is the failure HRESULT 2147746290 (0x800401F2, signed -2147221006) from winerror.h. The documented description is “Class of object cannot be determined”. In practical terms, COM cannot determine the class of the object or persisted data being activated. Interpret it in the context of loading an object when class identity must be obtained from storage, file metadata, or another descriptor.
Relevant contract
- Associate this result with one exact operation in thread apartment initialization, GUID parsing, class-object discovery, local-server launch, and single-use class-factory registration.
- Confirm that this result came from loading an object when class identity must be obtained from storage, file metadata, or another descriptor, rather than from cleanup or a wrapper that ran afterward.
Likely cause branches
- It can result when the storage lacks a valid root CLSID.
- It can result when file or persistence metadata is corrupt or incomplete.
- It can result when a wrapper passes uninitialized class information to an OLE loading helper.
Evidence to preserve
A useful incident records the thread ID and apartment request, CLSID text, IID text, class context, server executable or DLL path, process launch result, class-factory registration flags, timeout, and activation generation.
- Record storage CLSID, file type, persistence API, and source provenance.
- Inspect metadata without guessing from extension alone.
- Compare with a known-good object created by the same server version.
Diagnostic sequence
- Identify the exact object, method, and lifecycle phase involved in loading an object when class identity must be obtained from storage, file metadata, or another descriptor.
Recovery and retry
Correction: regenerate or repair the object through its owning application, or supply an explicit validated CLSID when the API allows it. Retry condition. Retry only with corrected class metadata; repeatedly probing unrelated classes can execute the wrong server. Before repeating the operation, balance successful CoInitializeEx calls on the same thread, revoke only class objects actually registered, and determine whether a local server or single-use factory already served a request.
Practical scenario
A compound file was copied before its root class ID was committed; resaving it in the owning application restores the class identity.
Difference from related HRESULTs
CO_E_CLASSSTRING concerns parsing textual CLSID input; it concerns discovering class identity from an object or persisted representation.
Developer and administrator guidance
Record the activation phase, parse GUID text before lookup, initialize every participating thread explicitly, and make class-object registration lifetime visible in server state. Regression coverage should include uninitialized and incompatibly initialized threads, malformed CLSID and IID text, missing applications, launch failure, factory-registration races, and single-use consumption.
Verify the registered application and server executable with the supported installation path; thread initialization and class-factory lifetime defects require code fixes rather than registry improvisation.
References
Looking for a different code? Search another status or error code.