What does HRESULT 0x80041651 (QPLIST_E_CANT_OPEN_FILE) mean?

 
Previous Next
QUERY_E_DUPLICATE_RANGE_NAME QPLIST_E_READ_ERROR

QPLIST_E_CANT_OPEN_FILE

The property-list file cannot be opened

QPLIST_E_CANT_OPEN_FILE is the failure HRESULT 0x80041651 (-2147215791 signed; 2147751505 unsigned). Its severity bit is 1, facility is 4 (FACILITY_ITF), and code is 0x1651. AllStat describes it as “Can not open file.”

Where the failure belongs

This result belongs to legacy Windows property-list parsing and is returned while opening the external query-property definition before parsing begins. The exact condition is: the configured file is missing, resolves under a different service directory, or is unreadable by the service identity. 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 belongs to the legacy property-list parser used to describe indexed properties and their types. Diagnose the external list as structured configuration: preserve line, column, token, type grammar and the property-list version instead of treating the file as arbitrary text. The exact public message comes from the legacy SDK contract; current property-system documentation does not replace the property-list grammar that rejected this file.

Likely causes

  • changes in resolved path between validation and execution can reproduce the result even when the user-visible input looks unchanged.
  • Retrying this result with the same service identity leaves the decisive contract violation intact.
  • This result can appear when file attributes and owner disagrees with the state expected while opening the external query-property definition before parsing begins.
  • a stale or transformed working directory and expansions can make the component observe that the configured file is missing, resolves under a different service directory, or is unreadable by the service identity.
  • an incomplete known-good file hash hides the distinction needed to separate this HRESULT from a later catalog or service failure.

The strongest hypothesis for it must account for the operation—opening the external query-property definition before parsing begins—and the documented condition. Rejection of the property list does not yet distinguish file access, tokenization, type composition, GUID syntax or duplicate-definition failure.

Telemetry that matters

  • record the source and normalization path of resolved path, not only its display form.
  • use service identity to test whether the failure belongs to parsing, execution, indexing or capability negotiation.
  • preserve file attributes and owner before objects or work items are released.
  • associate working directory and expansions with the exact UTC timestamp and correlation identifier.
  • compare failing and known-good values for known-good file hash under the same provider or handler version.
  • record the source and normalization path of property-list file identity and hash, not only its display form.

Evidence for it should reflect what the component actually received. Hash the complete file if it is sensitive while retaining encoding, line, column, raw token class and the surrounding property declaration.

Verification workflow

  1. Capture resolved path and service identity at the call boundary that returns this result.
  2. confirm the operation reached opening the external query-property definition before parsing begins with the intended file attributes and owner.
  3. perform the decisive check: resolve the path in the actual process context and prove a minimal read succeeds.
  4. reduce the case until changing working directory and expansions alone changes the HRESULT or proves it irrelevant.
  5. apply the recovery only after verifying known-good file hash; preserve the original result for comparison.

A useful control for it changes one dimension at a time. Begin with a one-property list accepted by the same parser, then restore the failing declaration token by token while preserving encoding and line endings.

Safe remediation

Restore a trusted readable file or correct the path/ACL without granting broad write access. Retry it only after the responsible input or state changes and the previous operation has completed or been cancelled. Delay cannot repair a deterministic file, token or type-grammar defect; retry only after the property list or its readable source changes.

Avoid the wrong conclusion

It does not prove that every property definition is unusable or that reindexing is required; it identifies a property-list read or grammar boundary. Without code-specific evidence for it, the value also cannot identify which wrapper, configuration, handler or service transition introduced the condition.

How nearby codes differ

QPLIST_E_READ_ERROR occurs after the file was opened and input failed later. 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 the property-list file hash, encoding, parser version, line and column, raw token and expected grammar production. Do not log credentials or unrestricted document content. Before replacing the whole property configuration for it, validate a copied file and preserve the exact failing location.

Worked example

A relative path works in an administrator shell but resolves elsewhere for the service. Logging the full resolved path identifies the deployment defect. A regression test for it 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.