| Previous | Next |
| QUERY_E_INVALID_DIRECTORY | QUERY_S_NO_QUERY |
QUERY_E_DIR_ON_REMOVABLE_DRIVE
The query directory is on removable media
QUERY_E_DIR_ON_REMOVABLE_DRIVE is the failure HRESULT 0x8004160B (-2147215861 signed; 2147751435 unsigned). Its severity bit is 1, facility is 4 (FACILITY_ITF), and code is 0x160B. AllStat describes it as “Specified directory is on a removable medium.”
Legacy API stage
This result belongs to legacy Windows query execution and is returned while classifying the volume that backs an otherwise resolved directory scope. The exact condition is: a legacy media-policy restriction rather than path syntax or ordinary file-access failure. 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 Indexing Service query-execution contract. It can surface through the Indexing Service OLE DB provider or related query interfaces, but it should not be presented as a generic result from every modern Windows Search API. Current Windows Search SQL documentation can clarify related clause concepts, but it does not establish that every current search API returns this legacy query-execution constant.
Why it appears
- a stale or transformed volume GUID can make the component observe that a legacy media-policy restriction rather than path syntax or ordinary file-access failure.
- an incomplete drive type hides the distinction needed to separate this HRESULT from a later catalog or service failure.
- changes in mount history between validation and execution can reproduce the result even when the user-visible input looks unchanged.
- Retrying this result with the same catalog eligibility leaves the decisive contract violation intact.
- This result can appear when fixed-volume control scope disagrees with the state expected while classifying the volume that backs an otherwise resolved directory scope.
The strongest hypothesis for this HRESULT must account for the operation—classifying the volume that backs an otherwise resolved directory scope—and the documented condition. A failed command or empty rowset is only the visible symptom; it does not identify which restriction, projection, sort, scope, timeout or catalog state violated the query contract.
Developer evidence
- associate volume GUID with the exact UTC timestamp and correlation identifier.
- compare failing and known-good values for drive type under the same provider or handler version.
- record the source and normalization path of mount history, not only its display form.
- use catalog eligibility to test whether the failure belongs to parsing, execution, indexing or capability negotiation.
- preserve fixed-volume control scope before objects or work items are released.
- associate provider command text and dialect with the exact UTC timestamp and correlation identifier.
Evidence for this HRESULT should reflect what the component actually received. Redact private literals if necessary, but keep clause boundaries, canonical properties, parameter types, dialect and parser or provider offsets.
Disciplined troubleshooting
- Capture volume GUID and drive type at the call boundary that returns this result.
- confirm the operation reached classifying the volume that backs an otherwise resolved directory scope with the intended mount history.
- perform the decisive check: resolve the current volume GUID and drive type instead of trusting a remembered drive letter.
- reduce the case until changing catalog eligibility alone changes the HRESULT or proves it irrelevant.
- apply the recovery only after verifying fixed-volume control scope; preserve the original result for comparison.
A useful control for this HRESULT changes one dimension at a time. Begin with a known-good minimal command against the same catalog and restore projection, restriction, sorting, grouping and scope one component at a time.
Retry conditions
Move the searchable scope to supported fixed/cataloged storage or use another search mechanism. Retry it only after the responsible input or state changes and the previous operation has completed or been cancelled. Backoff helps only with measured transient load or timeout; it cannot repair invalid clauses, projection metadata, scopes or command state.
Misleading assumptions
It does not by itself prove catalog corruption, service outage, access denial or absence of matches; the query stage and provider records must identify the failing clause or state. Without code-specific evidence for this HRESULT, the value also cannot identify which wrapper, configuration, handler or service transition introduced the condition.
Related query outcomes
QUERY_E_INVALID_DIRECTORY means the directory identifier is invalid; this value means resolution reached removable-media classification. 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 command text, dialect, catalog generation, parameter values, timeout, cancellation state and chained OLE DB error records. Do not log credentials or unrestricted document content. Before rebuilding the catalog or restarting the provider for this HRESULT, reproduce the minimal command and preserve its chained errors.
Concrete troubleshooting case
A saved E: scope begins pointing to a USB archive after drive reassignment. Volume-aware validation sends the user to a supported indexed location. 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: Indexing Service query-execution values
- Microsoft: OLE DB provider for Indexing Service
- Microsoft: Windows Search WHERE clause
- Microsoft: HRESULT values
Looking for a different code? Search another status or error code.