| Previous | Next |
| FILTER_E_OFFLINE | WBREAK_E_END_OF_TEXT |
FILTER_E_PARTIALLY_FILTERED
Only part of the document was emitted by the filter
FILTER_E_PARTIALLY_FILTERED is HRESULT 0x8004173E (-2147215554 signed; 2147751742 unsigned). Its severity bit is 1, facility is 4 (FACILITY_ITF for these values), and code field is 0x173E. Standard HRESULT severity rules classify the value as a failure. AllStat describes the value as “The document was too large to filter in its entirety. Portions of the document were not emitted.”
API stage and meaning
This result belongs to continuing extraction until an implementation or policy limit stops further chunks. The decisive interpretation is that some searchable content is valid, but coverage is incomplete because the document exceeded a filtering limit. 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.
Failure paths
- The result investigation should record expanded content crosses a size ceiling.
- The result investigation should record too many sections or attachments are encountered.
- The result investigation should record resource safeguards stop deep traversal.
- The result investigation should record a handler-specific maximum truncates extraction.
The useful hypothesis for it must explain both continuing extraction until an implementation or policy limit stops further chunks and the documented condition. Compare the failing case with a control that preserves count and identifiers of emitted chunks and changes only physical and expanded size; this prevents unrelated environment differences from dominating the result test.
Observability checklist
- At step 1 for it, count and identifiers of emitted chunks
- At step 2 for it, physical and expanded size
- At step 3 for it, limit or quota that ended extraction
- At step 4 for it, which sections or attachments were omitted
Capture count and identifiers of emitted chunks before releasing objects, closing handles or reconnecting. Retain the raw HRESULT with physical and expanded size, 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.
How to isolate the cause
- Commit already emitted chunks with an explicit partial flag. Associate this observation specifically with this result.
- Determine the precise limit rather than assuming generic corruption.
- Compare a smaller controlled document from the same producer.
- Assess whether omitted regions contain security-sensitive or business-critical content. 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 some searchable content is valid, but coverage is incomplete because the document exceeded a filtering limit. This isolates whether it is causal rather than merely repeatable.
Remediation policy
Keep valid emitted content, and retry only with a higher approved limit, reduced document, or specialized extractor. Record whether continuing extraction until an implementation or policy limit stops further chunks 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 count and identifiers of emitted chunks or physical and expanded size. A timer alone cannot demonstrate that the result contract condition has changed.
Wrong conclusions to avoid
It does not mean every chunk is unreliable, and it is not equivalent to total rejection by <code>FILTER_E_TOO_BIG</code>. Without the call boundary for continuing extraction until an implementation or policy limit stops further chunks, it also cannot identify which wrapper or configuration layer introduced the condition.
Comparison
FILTER_E_TOO_BIGIt telemetry, preserve neighboring constants separately because the same visible symptom may require a different caller action, owner or recovery gate.
Developer and administrator actions
- It: At the code boundary, keep count and identifiers of emitted chunks beside the returned HRESULT.
- It: In telemetry, correlate physical and expanded size with the target and component generation.
- It: For regression coverage, force the documented condition: some searchable content is valid, but coverage is incomplete because the document exceeded a filtering limit.
- It: For operations staff, expose the corrective state change rather than a generic retry button.
- It: After remediation, validate one known-good control and the original failing case.
Worked scenario
A container yields its first hundred attachments before the handler limit is reached. Search marks coverage partial and preserves the extracted parent text. 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: IFilter interface
- Microsoft: testing filter handlers
- Microsoft: filter handlers in Windows Search
- Microsoft: Filter-Interface values
Looking for a different code? Search another status or error code.