| Previous | Next |
| FILTER_E_LINK_UNAVAILABLE | FILTER_E_UNKNOWNFORMAT |
FILTER_E_PASSWORD
Password protection prevents document filtering
FILTER_E_PASSWORD is HRESULT 0x8004170B (-2147215605 signed; 2147751691 unsigned). Its severity bit is 1, facility is 4 (FACILITY_ITF for these values), and code field is 0x170B. Standard HRESULT severity rules classify the value as a failure. AllStat describes the value as “File was not filtered due to password protection.”
State represented by the HRESULT
This result belongs to opening encrypted or password-protected content before chunks can be extracted. The decisive interpretation is that the filter cannot obtain clear document content with the credentials and APIs available to the indexing host. 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 document requires an open password
- At step 2 for it, rights-management policy denies the service identity
- At step 3 for it, a saved credential is absent or expired
- At step 4 for it, the filter deliberately refuses interactive password prompts
The useful hypothesis for it must explain both opening encrypted or password-protected content before chunks can be extracted and the documented condition. Compare the failing case with a control that preserves document protection type without recording secrets and changes only filter handler and version; this prevents unrelated environment differences from dominating the result test.
Data for diagnosis
- This result: Document protection type without recording secrets.
- This result: Filter handler and version.
- This result: Identity of the noninteractive host.
- It: Whether metadata was available before decryption.
Capture document protection type without recording secrets before releasing objects, closing handles or reconnecting. Retain the raw HRESULT with filter handler and version, 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
- Confirm the file is actually protected using its owning application. Associate this observation specifically with it.
- Determine whether the filter supports noninteractive decryption. Associate this observation specifically with it.
- Check enterprise rights and key availability for the service identity. Associate this observation specifically with it.
- Classify already emitted metadata separately from protected body text. 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 filter cannot obtain clear document content with the credentials and APIs available to the indexing host. This isolates whether it is causal rather than merely repeatable.
Correct response
Supply content through an approved decrypted workflow or grant the intended service identity access. Do not log or repeatedly guess passwords. Record whether opening encrypted or password-protected content before chunks can be extracted 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 document protection type without recording secrets or filter handler and version. A timer alone cannot demonstrate that the result contract condition has changed.
Scope of the signal
It does not establish that the password is wrong; no credential may have been offered at all. Without the call boundary for opening encrypted or password-protected content before chunks can be extracted, it also cannot identify which wrapper or configuration layer introduced the condition.
Related HRESULT values
FILTER_E_ACCESS is a broader access failure, whereas it identifies document protection as the barrier. 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 document protection type without recording secrets beside the returned HRESULT.
- check In telemetry, correlate filter handler and version with the target and component generation.
- check For regression coverage, force the documented condition: the filter cannot obtain clear document content with the credentials and APIs available to the indexing host.
- 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 crawler receives searchable filenames but no body text from encrypted Office documents. A controlled ingestion path decrypts approved files before indexing. 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: filter handlers in Windows Search
- Microsoft: IFilter interface
- Microsoft: testing filter handlers
Looking for a different code? Search another status or error code.