| Previous | Next |
| CI_E_USE_DEFAULT_PID | CI_E_UPDATES_DISABLED |
CI_E_DUPLICATE_NOTIFICATION
A second notification exists for the same work ID
CI_E_DUPLICATE_NOTIFICATION is HRESULT 0x80041817. Windows documents it as “There were two notifications for the same workid.”
API stage and meaning
This result belongs to queuing or processing content-index change notifications. The system receives duplicate change information for one indexed item within the relevant sequence.
Failure paths
- A watcher retries without an idempotency key.
- Two monitoring sources report the same change.
- Acknowledgment loss causes replay.
- Work-ID mapping merges distinct paths incorrectly.
Compare the failing case with a control that preserves work ID and catalog generation and changes only notification type and sequence; this prevents unrelated environment differences from dominating the test.
Observability checklist
- At step 1, work ID and catalog generation
- At step 2, notification type and sequence
- At step 3, producer identity
- At step 4, delivery and acknowledgment timestamps
Capture work ID and catalog generation before releasing objects, closing handles or reconnecting. Retain the raw HRESULT with notification type and sequence, component version, UTC timestamp and correlation ID.
How to isolate the cause
- Compare payloads and sequence numbers.
- Determine whether the duplicate is harmless replay or conflicting data.
- Deduplicate at the documented ownership boundary.
- Verify two source paths were not incorrectly mapped to one work ID.
Preserve the component version and target identity, then alter only the condition described as the system receives duplicate change information for one indexed item within the relevant sequence.
Remediation policy
Suppress an identical replay after preserving evidence; process a genuinely newer change under correct ordering. Record whether queuing or processing content-index change notifications produced any content, update or state transition before returning.
Retry only after a concrete change in work ID and catalog generation or notification type and sequence.
Wrong conclusions to avoid
It does not mean the indexed document is duplicated in storage. Without the call boundary for queuing or processing content-index change notifications, it also cannot identify which wrapper or configuration layer introduced the condition.
Comparison
CI_E_OUTOFSEQ_INCREMENT_DATA concerns ordering of incremental-load data, not duplicate notification delivery.
Developer and administrator actions
- Record work ID and catalog generation with the returned HRESULT.
- In telemetry, correlate notification type and sequence with the target and component generation.
- For regression coverage, force the documented condition: the system receives duplicate change information for one indexed item within the relevant sequence.
- For operations staff, expose the corrective state change rather than a generic retry button.
- After remediation, validate one known-good control and the original failing case.
Worked scenario
A watcher times out waiting for acknowledgment and resends the same update. A stable notification ID makes processing idempotent.
Official Microsoft references
- Microsoft: content-indexing helper-function values — official contract information relevant to this HRESULT.
- Microsoft: Content-Indexing values
- Microsoft: HRESULT values
- Microsoft: Windows Search SQL syntax
Looking for a different code? Search another status or error code.