What does HRESULT 0x80041675 (QPARSE_E_INVALID_SORT_ORDER) mean?

 
Previous Next
QPARSE_E_NO_SUCH_SORT_PROPERTY QUTIL_E_CANT_CONVERT_VROOT

QPARSE_E_INVALID_SORT_ORDER

The sort direction token is invalid

QPARSE_E_INVALID_SORT_ORDER is the failure HRESULT 0x80041675 (-2147215755 signed; 2147751541 unsigned). Its severity bit is 1, facility is 4 (FACILITY_ITF), and code is 0x1675. AllStat describes it as “An invalid sort order was specified. Only [a] and [d] are supported.”

Contract and failing stage

This result belongs to legacy Windows query parsing and is returned while reading ascending/descending syntax for a valid sort key. The exact condition is: the affected legacy grammar accepts only [a] and [d], while a generic builder emits other words or booleans. 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.

Conditions that produce it

  • changes in raw direction between validation and execution can reproduce the result even when the user-visible input looks unchanged.
  • Retrying this result with the same query form leaves the decisive contract violation intact.
  • This result can appear when sort key disagrees with the state expected while reading ascending/descending syntax for a valid sort key.
  • a stale or transformed builder branch can make the component observe that the affected legacy grammar accepts only [a] and [d], while a generic builder emits other words or booleans.
  • an incomplete ascending/descending control hides the distinction needed to separate this HRESULT from a later catalog or service failure.

The strongest hypothesis for this HRESULT must account for the operation—reading ascending/descending syntax for a valid sort key—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.

Evidence to preserve

  • record the source and normalization path of raw direction, not only its display form.
  • use query form to test whether the failure belongs to parsing, execution, indexing or capability negotiation.
  • preserve sort key before objects or work items are released.
  • associate builder branch with the exact UTC timestamp and correlation identifier.
  • compare failing and known-good values for ascending/descending control under the same provider or handler version.
  • record the source and normalization path of final parser input bytes, not only its display form.

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.

Diagnostic sequence

  1. Capture raw direction and query form at the call boundary that returns this result.
  2. confirm the operation reached reading ascending/descending syntax for a valid sort key with the intended sort key.
  3. perform the decisive check: capture raw direction, query form and builder branch.
  4. reduce the case until changing builder branch alone changes the HRESULT or proves it irrelevant.
  5. apply the recovery only after verifying ascending/descending control; 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.

Recovery and retry

Map ascending and descending to the documented dialect tokens without localization. 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.

What the code does not prove

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.

Related HRESULT values

QPARSE_E_NO_SUCH_SORT_PROPERTY rejects key identity, not direction. 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.

Practical scenario

A shared builder emits `DESC`; a legacy serializer emits `[d]` and preserves descending order. 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

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