| Previous | Next |
| CI_E_BUFFERTOOSMALL | CI_E_INVALID_STATE |
CI_E_PROPERTY_NOT_CACHED
The requested property is not present in the property cache
CI_E_PROPERTY_NOT_CACHED is HRESULT 0x8004180D (-2147215347 signed; 2147751949 unsigned). Its severity bit is 1, facility is 4 (FACILITY_ITF for these values), and code field is 0x180D. Standard HRESULT severity rules classify the value as a failure. AllStat describes the value as “The given property is not cached.”
Interpretation in context
This result belongs to retrieving a cached property for a catalog item or query result. The decisive interpretation is that the schema or indexing policy did not store that property in the cache used by the helper. Keep the symbolic constant and method stage together in logs; its hexadecimal value alone cannot identify the owning transition or input.
The legacy content-index helper layer has explicit object, catalog and service states. In the result investigation, a generic retry can hide lifecycle, ordering or policy defects. This context narrows the responsible component without replacing the code-specific checks below.
Conditions to test
- This result: The property was never configured as cached.
- This result: The item predates a schema change.
- This result: The file handler did not emit the property.
- It: The caller confuses retrievable source metadata with cached catalog data.
The useful hypothesis for it must explain both retrieving a cached property for a catalog item or query result and the documented condition. Compare the failing case with a control that preserves canonical property identity and changes only catalog/schema generation; this prevents unrelated environment differences from dominating the result test.
Incident record
- check canonical property identity.
- check catalog/schema generation.
- check item work ID and indexing time.
- check properties configured and actually emitted.
Capture canonical property identity before releasing objects, closing handles or reconnecting. Retain the raw HRESULT with catalog/schema generation, 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.
Step-by-step diagnosis
- Verify the property is cache-enabled in the target catalog. Associate this observation specifically with it.
- Reindex a controlled item after any schema change. Associate this observation specifically with it.
- Inspect filter output for the property. Associate this observation specifically with it.
- Use an alternate retrieval path only when its cost and permissions are acceptable. 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 schema or indexing policy did not store that property in the cache used by the helper. This isolates whether it is causal rather than merely repeatable.
Retry decision
Change cache configuration and reindex, or handle absence. Repeating the same cache lookup cannot populate the value. Record whether retrieving a cached property for a catalog item or query result 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 canonical property identity or catalog/schema generation. A timer alone cannot demonstrate that the result contract condition has changed.
What the value cannot establish
It does not prove that the source document lacks the property. Without the call boundary for retrieving a cached property for a catalog item or query result, it also cannot identify which wrapper or configuration layer introduced the condition.
Adjacent contract states
CI_E_USE_DEFAULT_PID means an unsupported property ID should fall back; this HRESULT says a valid property is not cached. 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 the code boundary, keep canonical property identity beside the returned HRESULT; preserve the observation under the result correlation record.
- In telemetry, correlate catalog/schema generation with the target and component generation; preserve the observation under the result correlation record.
- For regression coverage, force the documented condition: the schema or indexing policy did not store that property in the cache used by the helper; preserve the observation under the result correlation record.
- For operations staff, expose the corrective state change rather than a generic retry button; preserve the observation under the result correlation record.
- After remediation, validate one known-good control and the original failing case; preserve the observation under the result correlation record.
Concrete scenario
A new custom property is added to query projections but old items were not reindexed. Catalog-generation telemetry explains mixed results. 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 helper-function values — official contract information relevant to it.
- Microsoft: Content-Indexing values
- Microsoft: IFilter::Init
- Microsoft: IFilter::GetValue
- Microsoft: HRESULT values
Looking for a different code? Search another status or error code.