| Previous | Next |
| FILTER_E_UNREACHABLE | FILTER_E_NOT_OPEN |
FILTER_E_IN_USE
Another process is using the document in an incompatible way
FILTER_E_IN_USE is HRESULT 0x80041738 (-2147215560 signed; 2147751736 unsigned). Its severity bit is 1, facility is 4 (FACILITY_ITF for these values), and code field is 0x1738. Standard HRESULT severity rules classify the value as a failure. AllStat describes the value as “The document is in use by another process.”
State represented by the HRESULT
This result belongs to opening content that is reachable but locked against the access mode required by the handler. The decisive interpretation is that a sharing or application-level lock prevents a stable filtering read. Keep the symbolic constant and method stage together in logs; its hexadecimal value alone cannot identify the owning transition or input.
The IFilter contract is stateful: GetChunk selects a chunk, then GetText or GetValue consumes content according to STAT_CHUNK flags. In the result investigation, method order and filter-instance ownership are therefore part of the evidence. This context narrows the responsible component without replacing the code-specific checks below.
Likely triggers
- At step 1 for it, the producer saves with exclusive sharing
- At step 2 for it, antivirus or conversion software temporarily owns the file
- At step 3 for it, the handler requests stronger access than necessary
- At step 4 for it, a stale lock remains after an abnormal process exit
The useful hypothesis for it must explain both opening content that is reachable but locked against the access mode required by the handler and the documented condition. Compare the failing case with a control that preserves locking process when available and changes only requested share and access modes; this prevents unrelated environment differences from dominating the result test.
Data for diagnosis
- This result: Locking process when available.
- This result: Requested share and access modes.
- This result: File identity and last-write time.
- It: Duration and recurrence of the lock.
Capture locking process when available before releasing objects, closing handles or reconnecting. Retain the raw HRESULT with requested share and access modes, component version, UTC timestamp and correlation ID. Bound the result telemetry to diagnostic metadata because document content, credentials and unrestricted query text may be sensitive.
Investigation order
- Attempt a read with the same sharing semantics. Associate this observation specifically with it.
- Identify the producer and whether the lock is part of an atomic save. Associate this observation specifically with it.
- Wait for file size and write time to stabilize. Associate this observation specifically with it.
- Avoid copying a half-written file merely to bypass the lock. Associate this observation specifically with it.
Change one variable per it control run. Preserve the component version and target identity, then alter only the condition described as a sharing or application-level lock prevents a stable filtering read. This isolates whether it is causal rather than merely repeatable.
Correct response
Use bounded delayed retry after the writer closes the document. Escalate persistent locks instead of spinning. Record whether opening content that is reachable but locked against the access mode required by the handler produced any content, update or state transition before returning. If completion remains unknown, the path must not replay non-idempotent work until the owner confirms final state.
The retry gate for it should be a concrete change in locking process when available or requested share and access modes. A timer alone cannot demonstrate that the result contract condition has changed.
Scope of the signal
It does not imply an ACL denial, missing file or malformed document. Without the call boundary for opening content that is reachable but locked against the access mode required by the handler, it also cannot identify which wrapper or configuration layer introduced the condition.
Related HRESULT values
FILTER_E_ALREADY_OPEN is internal filter-instance state; it concerns competing ownership of the source document. In it telemetry, preserve neighboring constants separately because the same visible symptom may require a different caller action, owner or recovery gate.
Developer and administrator actions
- check At the code boundary, keep locking process when available beside the returned HRESULT.
- check In telemetry, correlate requested share and access modes with the target and component generation.
- check For regression coverage, force the documented condition: a sharing or application-level lock prevents a stable filtering read.
- check For operations staff, expose the corrective state change rather than a generic retry button.
- check After remediation, validate one known-good control and the original failing case.
Example in a pipeline
A desktop application rewrites a presentation under an exclusive lock. The indexer retries after the rename completes and receives stable bytes. In this scenario, handling it at its real contract boundary prevents the application from collapsing a precise state into an unhelpful generic “search failed” message.
Official Microsoft references
- Microsoft: Content-Indexing values — official contract information relevant to it.
- Microsoft: filter handlers in Windows Search
- Microsoft: IFilter interface
- Microsoft: testing filter handlers
- Microsoft: Filter-Interface values
Looking for a different code? Search another status or error code.