What does HRESULT 0x80041820 (CI_E_NOT_RUNNING) mean?

 
Previous Next
CI_E_TIMEOUT CI_E_CARDINALITY_MISMATCH

CI_E_NOT_RUNNING

The content-index service is not running

CI_E_NOT_RUNNING is HRESULT 0x80041820 (-2147215328 signed; 2147751968 unsigned). Its severity bit is 1, facility is 4 (FACILITY_ITF for these values), and code field is 0x1820. For CI_E_NOT_RUNNING, standard HRESULT severity rules classify the value as a failure. AllStat describes the value as “Service is not running.”

Contract boundary

CI_E_NOT_RUNNING belongs to connecting to or invoking the service before it has an active process and endpoint. The decisive interpretation is that the required service is stopped, failed during startup or has terminated. For CI_E_NOT_RUNNING, keep the symbolic constant and method stage together in logs; its hexadecimal value alone cannot identify the owning transition or input.

For CI_E_NOT_RUNNING, the legacy content-index helper layer has explicit object, catalog and service states. In the CI_E_NOT_RUNNING investigation, a generic retry can hide lifecycle, ordering or policy defects. This context narrows the responsible component without replacing the code-specific checks below.

Ways this state occurs

  • An administrator stopped the service; preserve the observation under the CI_E_NOT_RUNNING correlation record.
  • Startup fails because configuration or storage is invalid; preserve the observation under the CI_E_NOT_RUNNING correlation record.
  • The service crashes; preserve the observation under the CI_E_NOT_RUNNING correlation record.
  • The client contacts the host before service startup completes; preserve the observation under the CI_E_NOT_RUNNING correlation record.

The useful hypothesis for CI_E_NOT_RUNNING must explain both connecting to or invoking the service before it has an active process and endpoint and the documented condition. Compare the failing case with a control that preserves service state and process ID and changes only startup/termination events; this prevents unrelated environment differences from dominating the CI_E_NOT_RUNNING test.

Telemetry fields

  • The CI_E_NOT_RUNNING investigation should record service state and process ID.
  • The CI_E_NOT_RUNNING investigation should record startup/termination events.
  • The CI_E_NOT_RUNNING investigation should record configured dependencies.
  • The CI_E_NOT_RUNNING investigation should record client target and connection timestamp.

For CI_E_NOT_RUNNING, capture service state and process ID before releasing objects, closing handles or reconnecting. Retain the raw HRESULT with startup/termination events, component version, UTC timestamp and correlation ID. Bound the CI_E_NOT_RUNNING telemetry to diagnostic metadata because document content, credentials and unrestricted query text may be sensitive.

Verification sequence

  1. Query service state on the real target. Associate this observation specifically with CI_E_NOT_RUNNING.
  2. Inspect the first startup failure rather than repeated client errors. Associate this observation specifically with CI_E_NOT_RUNNING.
  3. Verify dependencies and catalog paths. Associate this observation specifically with CI_E_NOT_RUNNING.
  4. Reconnect only after an explicit running and ready indication. Associate this observation specifically with CI_E_NOT_RUNNING.

Change one variable per CI_E_NOT_RUNNING control run. Preserve the component version and target identity, then alter only the condition described as the required service is stopped, failed during startup or has terminated. This isolates whether CI_E_NOT_RUNNING is causal rather than merely repeatable.

Safe continuation

Start or repair the service, then create a fresh connection. Repeated immediate calls while stopped are noise. For CI_E_NOT_RUNNING, record whether connecting to or invoking the service before it has an active process and endpoint produced any content, update or state transition before returning. If completion remains unknown, the CI_E_NOT_RUNNING path must not replay non-idempotent work until the owner confirms final state.

The retry gate for CI_E_NOT_RUNNING should be a concrete change in service state and process ID or startup/termination events. A timer alone cannot demonstrate that the CI_E_NOT_RUNNING contract condition has changed.

Limits of the HRESULT

It does not mean a particular catalog is absent or filtering is disabled. Without the call boundary for connecting to or invoking the service before it has an active process and endpoint, CI_E_NOT_RUNNING also cannot identify which wrapper or configuration layer introduced the condition.

Distinguishing related codes

CI_E_SHUTDOWN describes an index in shutdown; CI_E_NOT_RUNNING directly reports service availability. In CI_E_NOT_RUNNING telemetry, preserve neighboring constants separately because the same visible symptom may require a different caller action, owner or recovery gate.

Developer and administrator actions

  • At step 1 for CI_E_NOT_RUNNING, at the code boundary, keep service state and process ID beside the returned HRESULT
  • At step 2 for CI_E_NOT_RUNNING, in telemetry, correlate startup/termination events with the target and component generation
  • At step 3 for CI_E_NOT_RUNNING, for regression coverage, force the documented condition: the required service is stopped, failed during startup or has terminated
  • At step 4 for CI_E_NOT_RUNNING, for operations staff, expose the corrective state change rather than a generic retry button
  • At step 5 for CI_E_NOT_RUNNING, after remediation, validate one known-good control and the original failing case

Practical case

A monitoring client starts before the indexing service after reboot. Dependency-aware startup removes the false incident. In this scenario, handling CI_E_NOT_RUNNING at its real contract boundary prevents the application from collapsing a precise state into an unhelpful generic “search failed” message.

Official Microsoft references

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