| Previous | Next |
| CO_E_APPNOTFOUND | CO_E_ERRORINAPP |
CO_E_APPSINGLEUSE
Application cannot be run more than once
When Windows returns CO_E_APPSINGLEUSE—HRESULT 2147746294, 0x800401F6, signed -2147221002—The documented description is “Application cannot be run more than once”. The actionable meaning is a single-use COM server application cannot be run or registered for another concurrent activation. The surrounding operation is activating a local server whose class factory is registered with single-use semantics.
Precise failure point
- 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 activating a local server whose class factory is registered with single-use semantics, rather than from cleanup or a wrapper that ran afterward.
Diagnostic evidence
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 server process ID, class-factory registration flags, activation timestamps, and revocation.
- Check whether the first client still owns a live object.
- Verify that server shutdown and CoRevokeClassObject paths complete.
Resolution path
- Identify the exact object, method, and lifecycle phase involved in activating a local server whose class factory is registered with single-use semantics.
Distinct causes
- It can result when an existing single-use instance still owns the class registration.
- It can result when the server fails to revoke or exit after serving its one activation.
- It can result when multiple callers race to activate a class designed for one client instance.
Retry policy
Correction: reuse the existing instance when the application contract allows, wait for clean shutdown, or redesign/register the server for multiple use if supported. Retry condition. Retry only after the prior single-use instance releases registration; use backoff and a bounded user-visible wait. 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
Two automation jobs start simultaneously against a REGCLS_SINGLEUSE server; serializing jobs prevents the second activation from racing the first instance.
Difference from related HRESULTs
CO_E_APPNOTFOUND cannot locate the server executable; it reaches the application model but rejects another run under single-use policy.
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.