What does HRESULT 0x8004173E (FILTER_E_PARTIALLY_FILTERED) mean?

FILTER_E_PARTIALLY_FILTERED

Only part of the document was emitted by the filter

FILTER_E_PARTIALLY_FILTERED is HRESULT 0x8004173E. Windows documents it 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. Some searchable content is valid, but coverage is incomplete because the document exceeded a filtering limit.

Failure paths

• Expanded content crosses a size ceiling.
• Too many sections or attachments are encountered.
• Resource safeguards stop deep traversal.
• A handler-specific maximum truncates extraction.

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 test.

Observability checklist

• At step 1, count and identifiers of emitted chunks
• At step 2, physical and expanded size
• At step 3, limit or quota that ended extraction
• At step 4, 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.

How to isolate the cause

1. Commit already emitted chunks with an explicit partial flag.
2. Determine the precise limit rather than assuming generic corruption.
3. Compare a smaller controlled document from the same producer.
4. Assess whether omitted regions contain security-sensitive or business-critical content.

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.

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.

Retry only after a concrete change in count and identifiers of emitted chunks or physical and expanded size.

Wrong conclusions to avoid

It does not mean every chunk is unreliable, and it is not equivalent to total rejection by FILTER_E_TOO_BIG. 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

• Record count and identifiers of emitted chunks with the returned HRESULT.
• In telemetry, correlate physical and expanded size with the target and component generation.
• For regression coverage, force the documented condition: some searchable content is valid, but coverage is incomplete because the document exceeded a filtering limit.
• 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 container yields its first hundred attachments before the handler limit is reached. Search marks coverage partial and preserves the extracted parent text.

Official Microsoft references

• Microsoft: Content-Indexing values — official contract information relevant to this HRESULT.
• Microsoft: IFilter interface
• Microsoft: testing filter handlers
• Microsoft: filter handlers in Windows Search
• Microsoft: Filter-Interface values