| Previous | Next |
| QPARSE_E_EXPECTING_REGEX | QPARSE_E_INVALID_LITERAL |
QPARSE_E_EXPECTING_REGEX_PROPERTY
Regex matching lacks a string property target
QPARSE_E_EXPECTING_REGEX_PROPERTY is the failure HRESULT 0x8004166D (-2147215763 signed; 2147751533 unsigned). Its severity bit is 1, facility is 4 (FACILITY_ITF), and code is 0x166D. AllStat describes it as “Regular expressions require a property of type string.”
Exact contract boundary
This result belongs to legacy Windows query parsing and is returned while validating the property side of a regular-expression comparison. The exact condition is: the property is absent or resolves to numeric, date, binary or vector data. This stage matters because converting the result to a generic COM failure removes the information needed to choose the owner and retry policy.
This value comes from the legacy Indexing Service query parser. The exact final string, parser mode, locale and target property schema matter more than the query text shown in a user interface, because escaping and serialization can alter the token stream before parsing. Current Search SQL documentation can help compare operators and property syntax, but the failing token must still be interpreted under this legacy parser dialect.
Input or state defects
- This result can appear when canonical property disagrees with the state expected while validating the property side of a regular-expression comparison.
- a stale or transformed actual DBTYPE can make the component observe that the property is absent or resolves to numeric, date, binary or vector data.
- an incomplete regex operator hides the distinction needed to separate this HRESULT from a later catalog or service failure.
- changes in UI field type between validation and execution can reproduce the result even when the user-visible input looks unchanged.
- Retrying this result with the same schema version leaves the decisive contract violation intact.
The strongest hypothesis for this HRESULT must account for the operation—validating the property side of a regular-expression comparison—and the documented condition. A parse failure does not identify the expected token class, property type, locale conversion or escaping layer until the final parser input is preserved.
Incident record
- preserve canonical property before objects or work items are released.
- associate actual DBTYPE with the exact UTC timestamp and correlation identifier.
- compare failing and known-good values for regex operator under the same provider or handler version.
- record the source and normalization path of UI field type, not only its display form.
- use schema version to test whether the failure belongs to parsing, execution, indexing or capability negotiation.
- preserve final parser input bytes before objects or work items are released.
Evidence for this HRESULT should reflect what the component actually received. Preserve a bounded token window, offsets, quote and delimiter state, locale and canonical property identity without logging unrelated query text.
How to isolate the cause
- Capture canonical property and actual DBTYPE at the call boundary that returns this result.
- confirm the operation reached validating the property side of a regular-expression comparison with the intended regex operator.
- perform the decisive check: capture canonical identity and actual catalog type before constructing the regex node.
- reduce the case until changing UI field type alone changes the HRESULT or proves it irrelevant.
- apply the recovery only after verifying schema version; preserve the original result for comparison.
A useful control for this HRESULT changes one dimension at a time. Begin with a minimal expression using the same property and parser mode, then add the failing literal, operator or delimiter without changing locale or escaping.
Restoration strategy
Allow regex only for string-valued properties and use type-appropriate alternatives elsewhere. Retry it only after the responsible input or state changes and the previous operation has completed or been cancelled. Retrying identical parser bytes cannot succeed; regenerate the specific token or schema pairing that failed.
Scope of the result
It does not prove that the user intent is invalid or that the catalog lacks data; it identifies how this parser interpreted the final serialized expression. Without code-specific evidence for this HRESULT, the value also cannot identify which wrapper, configuration, handler or service transition introduced the condition.
Comparison with adjacent codes
QPARSE_E_UNSUPPORTED_PROPERTY_TYPE is broader; this value names the regex string-property requirement. Keep the symbolic HRESULT beside the stage name in telemetry because nearby constants may require different owners, user messages and retry rules despite the same visible symptom.
Developer and administrator guidance
Retain final parser bytes, query form, token offset, expected token class, locale, escaping path and target property schema. Do not log credentials or unrestricted document content. Before changing catalog schema for this HRESULT, prove the final token stream and property type at the parser boundary.
Example from a search pipeline
A UI exposes regex for System.Size. The control changes to numeric range semantics. A regression test for this HRESULT should assert the decisive evidence, change only the responsible condition, and include one neighboring HRESULT so future code cannot collapse distinct failures into a generic message.
Official Microsoft references
- Microsoft: legacy Indexing Service error messages
- Microsoft: Windows Search WHERE clause
- Microsoft: Windows Search SQL syntax
- Microsoft: ISearchQueryHelper
Looking for a different code? Search another status or error code.