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. According to AllStat, it means “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.

The high bit in 0x80040111 is set, so this is a failure rather than a success or informational result. Its facility field is 4 (FACILITY_ITF) and its low 16-bit code is 273 (0x0111). Those bit fields classify the value, but they do not identify the failing object by themselves; the native method, object identity, and first producer of this result remain essential.

Operational meaning

Understanding this result requires this subsystem context: 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.
  • Preserve any IErrorInfo, underlying Win32 result, provider message, or callback failure that preceded it; the HRESULT alone should not erase a more specific cause.

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. Capture it at the first native return before a wrapper maps it to a generic exception.
  2. Identify the exact object, method, and lifecycle phase involved in asking a DLL or local server class object to create an object.
  3. Log the CLSID used for factory acquisition and the CLSID/version owned by the server.
  4. Capture module path, product version, class context, and registration source.
  5. Check whether the class factory is being reused after server configuration or plugin inventory changed.
  6. Reproduce it with one controlled input or state change, and verify that the correction changes the decisive evidence rather than merely hiding the result.

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. Also retain the application and component build, architecture, process and thread IDs, COM apartment, operation correlation ID, elapsed time, and the first state-changing event before the failure. When logging it, redact content and credentials while preserving types, lengths, hashes, opaque identities, and lifecycle generations needed to reproduce its contract.

Correction strategy

Correction. for it, repair the registration-to-binary mismatch, request the correct CLSID, or restart the server so it registers the intended factory. Retry boundary. 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. This isolates it within COM class factories and object creation and provides a regression test for the stated correction.

Difference from related HRESULTs

REGDB_E_CLASSNOTREG means activation cannot find registration; it means a reached class factory still cannot provide the class. Keep those outcomes separate in exception mappings, telemetry dimensions, user messages, and automated retry policy.

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 for it 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.

Operational repair for it must target the evidence-backed owner: 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. Retain before-and-after traces for it so the change can be attributed and reversed.

References

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