| Previous | Next |
| CO_E_IIDSTRING | CO_E_APPSINGLEUSE |
CO_E_APPNOTFOUND
Application not found
CO_E_APPNOTFOUND has hexadecimal value 0x800401F5 (unsigned 2147746293, signed -2147221003). Windows reports “Application not found”. The narrow interpretation is that the application required to serve the COM class cannot be found. The failing stage is launching an out-of-process COM server during activation.
API stage
- 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 launching an out-of-process COM server during activation, rather than from cleanup or a wrapper that ran afterward.
Verification steps
- Identify the exact object, method, and lifecycle phase involved in launching an out-of-process COM server during activation.
- Record CLSID, effective server command, expanded executable path, architecture, and package identity.
- Verify file existence and signature through deployment inventory.
- Check upgrade/uninstall logs for stale registration.
Interpretation limits
- It can result when LocalServer32 points to a missing or moved executable.
- It can result when path quoting or environment expansion resolves to a nonexistent program.
- It can result when an optional product component was not installed although registration remains.
Incident record
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.
Recovery conditions
Correction: repair or reinstall the owning application and its COM registration; remove stale registration only through supported deployment cleanup. Retry condition. Retry after deployment repair; repeatedly launching a missing path wastes time and can trigger misleading fallback behavior. 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
An upgrade moves the automation server but leaves the old LocalServer32 value; repairing the product updates the path and activation succeeds.
Difference from related HRESULTs
REGDB_E_CLASSNOTREG means no usable class registration; it means registration leads to an application that cannot be located.
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.