| Previous | Next |
| CI_S_NO_DOCSTORE | CI_S_NEW_AUXMETADATA |
CI_S_CAT_STOPPED
Indexing catalog is stopped
CI_S_CAT_STOPPED is HRESULT 268326 (0x00041826) from Indexing Service. AllStat describes it as “The catalog has been stopped.” The severity bit indicates a nonfailure result, but the value carries a specific condition that must not be collapsed into plain S_OK.
In the legacy Indexing Service or IFilter pipeline, this result means that the catalog has been stopped. Acceptance depends on the returned state and outputs, not only on the cleared severity bit.
Where the status is encountered
- Legacy Indexing Service catalog processing; log the exact method and object state instead of interpreting the constant outside that contract.
- IFilter text and property extraction; log the exact method and object state instead of interpreting the constant outside that contract.
- Search enumeration, scan scheduling, or catalog administration; log the exact method and object state instead of interpreting the constant outside that contract.
Because it is informational, a language binding may expose it as success and hide the symbolic distinction. Keep the original HRESULT available until the code-specific branch has run.
What must be true before accepting it
Verify that the stopped state is intentional or recoverable and no client assumes that catalog data is being updated. This check separates a legitimate it outcome from code that ignores an incomplete or altered operation.
Before retrying it, classify its effects as completed, partial, pending, cancelled, adapted, or terminal.
Evidence and telemetry
- preserve catalog state and stop time.
- preserve initiating user or service event.
- preserve pending scans.
- preserve last successful checkpoint.
- preserve restart result and freshness timestamp.
Also record ci_s_cat_stopped_operation, ci_s_cat_stopped_state_before, ci_s_cat_stopped_state_after, UTC time, process and thread identifiers, component version, and a correlation ID. When logging it, redact secret payloads but preserve stable identifiers and hashes needed for correlation.
Correct handling and recovery
Inspect service and catalog state, pending maintenance, storage health, and the stop initiator. Restart only after the reason is resolved and then verify freshness.
Retry it only when a documented input or state has changed. Do not immediately repeat it when the same stable state would produce the same informational result.
Difference from nearby results
It must be distinguished from ordinary S_OK and from failure-severity values in the same API family; its documented state changes control the next action.
The distinction around it determines whether the caller stops, waits, consumes output, or changes state.
Practical scenario
A catalog is stopped for volume maintenance. Search monitoring reports stale-but-available data, waits for the maintenance record to clear, then verifies indexing resumes.
A regression test should reproduce it, assert the relevant outputs and state, then change only the decisive condition and verify the expected neighboring result or ordinary completion.
References
- Microsoft: Filter interface values — official Microsoft material used to interpret it.
- Microsoft: About Indexing Service filters
- Microsoft: Using custom filters
- Microsoft: HRESULT values
Looking for a different code? Search another status or error code.