What does HRESULT 0x80041701 (FILTER_E_NO_MORE_TEXT) mean?

FILTER_E_NO_MORE_TEXT

All text in the current chunk has been returned

FILTER_E_NO_MORE_TEXT is HRESULT 0x80041701 (-2147215615 signed; 2147751681 unsigned). Its severity bit is 1, facility is 4 (FACILITY_ITF for these values), and code field is 0x1701. Its failure-severity encoding is a terminal condition for text in the current chunk; the caller advances with GetChunk. AllStat describes the value as “No more text available in chunk.”

Contract boundary

This result belongs to continuing IFilter::GetText for a text-bearing chunk. The decisive interpretation is that the current chunk remains valid, but its text stream is exhausted until GetChunk advances. 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.

Ways this state occurs

• The consumer requests another buffer after the last characters; preserve the observation under the result correlation record.
• The chunk contains zero additional characters after a previous partial read; preserve the observation under the result correlation record.
• State is reused without calling GetChunk; preserve the observation under the result correlation record.

The useful hypothesis for it must explain both continuing IFilter::GetText for a text-bearing chunk and the documented condition. Compare the failing case with a control that preserves chunk id and CHUNK_TEXT flag and changes only characters returned by every GetText call; this prevents unrelated environment differences from dominating the result test.

Telemetry fields

• The result investigation should record chunk id and CHUNK_TEXT flag.
• The result investigation should record characters returned by every GetText call.
• The result investigation should record input and output buffer lengths.
• The result investigation should record next method called by the consumer.

Capture chunk id and CHUNK_TEXT flag before releasing objects, closing handles or reconnecting. Retain the raw HRESULT with characters returned by every GetText call, 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.

Verification sequence

1. Check that the active chunk advertises text. Associate this observation specifically with this result.
2. Sum returned character counts and compare them with the caller loop.
3. Ensure the next operation is GetChunk rather than another unconditional GetText.
4. Test repeated GetText calls for the documented stable terminal response. 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 the current chunk remains valid, but its text stream is exhausted until GetChunk advances. This isolates whether it is causal rather than merely repeatable.

Safe continuation

Advance with GetChunk. Enlarging the buffer or retrying GetText cannot create more text in the same chunk. Record whether continuing IFilter::GetText for a text-bearing chunk 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 chunk id and CHUNK_TEXT flag or characters returned by every GetText call. A timer alone cannot demonstrate that the result contract condition has changed.

Limits of the HRESULT

It does not mean the document has no more chunks or that value chunks are unavailable. Without the call boundary for continuing IFilter::GetText for a text-bearing chunk, it also cannot identify which wrapper or configuration layer introduced the condition.

Distinguishing related codes

FILTER_E_NO_TEXT means the current chunk is not a text chunk; it means a text chunk was drained. 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

• At step 1 for it, at the code boundary, keep chunk id and CHUNK_TEXT flag beside the returned HRESULT
• At step 2 for it, in telemetry, correlate characters returned by every GetText call with the target and component generation
• At step 3 for it, for regression coverage, force the documented condition: the current chunk remains valid, but its text stream is exhausted until GetChunk advances
• At step 4 for it, for operations staff, expose the corrective state change rather than a generic retry button
• At step 5 for it, after remediation, validate one known-good control and the original failing case

Practical case

A client reads a long paragraph in several 4 KB buffers. The final read is followed by it, so it advances to the next chunk. 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: Filter-Interface values — official contract information relevant to it.
• Microsoft: IFilter::GetText
• Microsoft: IFilter::GetChunk
• Microsoft: testing filter handlers
• Microsoft: IFilter interface

Looking for a different code? Search another status or error code.