What does HRESULT 0x800401F6 (CO_E_APPSINGLEUSE) mean?

Status / error code:

Category:

Constant name:

Source:

Facility:

Operating System:

Description:

A single-use COM server application cannot be run or registered for another concurrent activation.

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—AllStat describes the condition as “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.

The high bit in 0x800401F6 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 502 (0x01F6). 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.

Precise failure point

Understanding this result requires this subsystem context: Early COM activation has discrete phases: thread initialization, identifier parsing, registration lookup, server launch, and class-factory registration. Preserve the first phase-specific result before a framework collapses it into a generic activation exception.

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

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

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

Capture it at the first native return before a wrapper maps it to a generic exception.
Identify the exact object, method, and lifecycle phase involved in activating a local server whose class factory is registered with single-use semantics.
Reproduce it with one controlled input or state change, and verify that the correction changes the decisive evidence rather than merely hiding the result.

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. for it, reuse the existing instance when the application contract allows, wait for clean shutdown, or redesign/register the server for multiple use if supported. Retry boundary. 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. This isolates it within COM initialization and early activation and provides a regression test for the stated correction.

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. Keep those outcomes separate in exception mappings, telemetry dimensions, user messages, and automated retry 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 for it should include uninitialized and incompatibly initialized threads, malformed CLSID and IID text, missing applications, launch failure, factory-registration races, and single-use consumption.

Operational repair for it must target the evidence-backed owner: 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. 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.