| Previous | Next |
| FDAEMON_E_PARTITIONDELETED | FDAEMON_E_WORDLISTCOMMITFAILED |
FDAEMON_E_CHANGEUPDATEFAILED
The filtered document could not update the change list
FDAEMON_E_CHANGEUPDATEFAILED is the failure HRESULT 0x80041684 (-2147215740 signed; 2147751556 unsigned). Its severity bit is 1, facility is 4 (FACILITY_ITF), and code is 0x1684. AllStat describes it as “Documents not stored in content index because update of changelist failed.”
Operation and state
This result belongs to legacy Windows content indexing and is returned while recording catalog change-tracking state after extraction so later indexing stages see the document update. The exact condition is: change-list storage, transaction, synchronization or generation state rejects the update even though filtering may have produced data. This stage matters because converting the result to a generic COM failure removes the information needed to choose the owner and retry policy.
This value belongs to the legacy filter daemon and content-indexing pipeline. It identifies failure while extracting or committing indexed content, so query syntax changes do not repair it. Preserve the document, filter handler and catalog generation that owned the work item. Current IFilter documentation clarifies handler extraction contracts, while the daemon HRESULT remains tied to the legacy content-indexing pipeline and its catalog generation.
Failure paths to examine
- a stale or transformed change-list transaction result can make the component observe that change-list storage, transaction, synchronization or generation state rejects the update even though filtering may have produced data.
- an incomplete catalog generation hides the distinction needed to separate this HRESULT from a later catalog or service failure.
- changes in document work ID between validation and execution can reproduce the result even when the user-visible input looks unchanged.
- Retrying this result with the same partial-commit state leaves the decisive contract violation intact.
- This result can appear when storage/service events disagrees with the state expected while recording catalog change-tracking state after extraction so later indexing stages see the document update.
The strongest hypothesis for it must account for the operation—recording catalog change-tracking state after extraction so later indexing stages see the document update—and the documented condition. An unindexed document is only the outcome; it does not identify the handler, resource, partition generation, change list or word-list stage that failed.
Data to collect first
- associate change-list transaction result with the exact UTC timestamp and correlation identifier.
- compare failing and known-good values for catalog generation under the same provider or handler version.
- record the source and normalization path of document work ID, not only its display form.
- use partial-commit state to test whether the failure belongs to parsing, execution, indexing or capability negotiation.
- preserve storage/service events before objects or work items are released.
- associate document identity and type with the exact UTC timestamp and correlation identifier.
Evidence for it should reflect what the component actually received. Hash document content while retaining file type, size, handler CLSID, extraction stage, block counts and catalog generation.
Step-by-step diagnosis
- Capture change-list transaction result and catalog generation at the call boundary that returns this result.
- confirm the operation reached recording catalog change-tracking state after extraction so later indexing stages see the document update with the intended document work ID.
- perform the decisive check: capture the change-list operation, catalog generation, storage error and whether the document was partially committed.
- reduce the case until changing partial-commit state alone changes the HRESULT or proves it irrelevant.
- apply the recovery only after verifying storage/service events; preserve the original result for comparison.
A useful control for it changes one dimension at a time. Run a copied document through the same filter version in an isolated queue and compare the exact extraction or commit stage with a known-good document type.
Continuation policy
Repair the change-tracking store or catalog state and reschedule the item with idempotent generation checks. Retry it only after the responsible input or state changes and the previous operation has completed or been cancelled. Retry only after resource pressure, handler behavior, work generation or catalog storage state changes and stale work is discarded.
Limits of this HRESULT
It does not prove that all documents or all filters are affected; preserve the triggering work item, handler and catalog generation before broad recovery. Without code-specific evidence for it, the value also cannot identify which wrapper, configuration, handler or service transition introduced the condition.
Distinguishing similar results
FDAEMON_E_WORDLISTCOMMITFAILED concerns publication of searchable terms rather than the change-list update. Keep the symbolic HRESULT beside the stage name in telemetry because nearby constants may require different owners, user messages and retry rules despite the same visible symptom.
Developer and administrator guidance
Retain the document identity, filter CLSID/version/bitness, daemon event, catalog generation and retry or quarantine history. Do not log credentials or unrestricted document content. Before rebuilding catalogs or reregistering every filter for it, isolate the document, handler and failed work generation.
Operational case
Extraction succeeds but the change-list transaction fails after a catalog maintenance event. A fresh crawl resubmits the item only after generation consistency is restored. A regression test for it should assert the decisive evidence, change only the responsible condition, and include one neighboring HRESULT so future code cannot collapse distinct failures into a generic message.
Official Microsoft references
- Microsoft: content-indexing values
- Microsoft: IFilter interface
- Microsoft: filter handlers
- Microsoft: HRESULT values
Looking for a different code? Search another status or error code.