What does HRESULT 0x80040111 (CLASS_E_CLASSNOTAVAILABLE) mean?

 
Previous Next
CLASS_E_NOAGGREGATION CLASS_E_NOTLICENSED

CLASS_E_CLASSNOTAVAILABLE

ClassFactory cannot supply requested class

The native value 0x80040111 is CLASS_E_CLASSNOTAVAILABLE, unsigned 2147746065 and signed -2147221231. The documented description is “ClassFactory cannot supply requested class”. Treat it as evidence that the obtained class factory cannot supply the requested class instance; the operation in progress is asking a DLL or local server class object to create an object.

Operational meaning

A COM class factory separates discovery of a class object from creation of an instance. Keeping those stages distinct reveals whether the defect is registration, factory selection, aggregation, licensing, or server implementation.

  • Associate this result with one exact operation in CoGetClassObject, IClassFactory::CreateInstance, aggregation rules, class availability, and optional licensing.
  • Confirm that this result came from asking a DLL or local server class object to create an object, rather than from cleanup or a wrapper that ran afterward.

Cause model

  • It can result when DllGetClassObject was asked for a CLSID the module does not implement.
  • It can result when a local server registered the wrong class factory or revoked it during shutdown.
  • It can result when binary and registration versions disagree, so activation reaches a server without that class.

Troubleshooting workflow

  1. Identify the exact object, method, and lifecycle phase involved in asking a DLL or local server class object to create an object.
  2. Log the CLSID used for factory acquisition and the CLSID/version owned by the server.
  3. Capture module path, product version, class context, and registration source.
  4. Check whether the class factory is being reused after server configuration or plugin inventory changed.

What to log

A useful incident records the CLSID, requested IID, class context, server path, pUnkOuter value, factory interface, activation machine, license path, and the first server-side return.

Correction strategy

Correction. repair the registration-to-binary mismatch, request the correct CLSID, or restart the server so it registers the intended factory. Retry condition. Retry can work after deployment repair or server re-registration, but not against the same factory that definitively rejects the class. Before repeating the operation, release any factory or partially initialized instance, determine whether a server process was launched, and avoid reusing a factory obtained before deployment or license state changed.

Practical scenario

An installer updates the COM registration to a new CLSID but leaves an older local server running; restarting the server aligns the registered factory with the installed build.

Difference from related HRESULTs

REGDB_E_CLASSNOTREG means activation cannot find registration; it means a reached class factory still cannot provide the class.

Developer and administrator guidance

Keep class-object discovery separate from CreateInstance, log pUnkOuter and the initial IID, and make licensed creation an explicit IClassFactory2 path. Regression coverage should include in-process and local-server contexts, null and non-null controlling unknowns, IID_IUnknown aggregation rules, stale factories after upgrade, and valid versus missing license state.

Verify the registered server path and product version with the supported installer, and use the vendor’s licensing mechanism rather than copying registration or license material between machines.

References


Looking for a different code? Search another status or error code.