| Previous | Next |
| CO_E_INIT_SCM_EXEC_FAILURE | CO_E_CANT_REMOTE |
CO_E_INIT_ONLY_SINGLE_THREADED
COM initialization conflicts with single-threaded setup
CO_E_INIT_ONLY_SINGLE_THREADED is HRESULT 2147500050 (0x80004012) from winerror.h. AllStat describes it as “There was an attempt to call CoInitialize a second time while single threaded.” The value must be interpreted at legacy single-threaded COM initialization and repeated initialization on the same thread, because the same high-level symptom can come from a different contract boundary and require different cleanup.
The decisive Interpretation is that the thread attempted an initialization sequence incompatible with its existing single-threaded COM state. Treat this result as a contract result from its owning subsystem and retain the unmodified HRESULT in logs and test assertions.
Where the result appears
- This result may surface in legacy single-threaded COM initialization and repeated initialization on the same thread.
- The first boundary to preserve for it is the exact activation, initialization, call-control, or lifetime step that returned it.
- record whether the failure occurred before an object identity existed, while a method was running, or during shutdown; those phases imply different ownership and retry rules.
Map this result to one concrete invocation and one concrete object or metadata identity before interpreting the human-readable description.
Typical causes and interpretation boundary
Common cause categories for it are: a library reinitializes the thread with incompatible assumptions; COM is initialized from nested startup code; apartment ownership is unclear. The evidence should distinguish configuration, lifetime, input, identity, resource, and version failures rather than grouping them.
The check that separates this result from nearby HRESULTs is: the thread attempted an initialization sequence incompatible with its existing single-threaded COM state. The text of it narrows the search, but the owning API state must confirm the condition before automation changes the system.
Correct handling and recovery
The appropriate recovery is to choose the apartment model once at thread entry, treat S_FALSE as successful initialization, balance each successful call, and remove hidden reinitialization. Recovery from it should name the component responsible for retry and the evidence that makes another attempt safe.
The failure path for it should leave outputs in a known state and avoid double release, double commit, or reuse of stale pointers.
Practical scenario
A UI thread is initialized by the host and a plug-in repeats a legacy initialization path that assumes it owns the apartment.
To prevent recurrence of it, preserve a minimal fixture that asserts both the failing condition and the state after recovery.
Difference from related HRESULTs
RPC_E_CHANGED_MODE is the modern explicit apartment-model conflict; this code belongs to an older COM initialization path.
Classify it by the stated contract difference, since severity bits alone do not determine the correct response.
Developer and administrator guidance
Code handling it should classify it by lifecycle and ownership rather than by the high bit alone. For <code>it</code>, initialization failures normally require rebuilding the process or thread environment, capability results require a fallback, and uncertain remote outcomes require reconciliation before retry.
Operational dashboards should keep it distinct from generic COM failures and attach deployment, service, package, runtime, policy, and architecture dimensions. Administrators should avoid broad registry edits, blanket firewall changes, or permission expansion unless the captured evidence for it identifies that subsystem.
References
Looking for a different code? Search another status or error code.