| Previous | Next |
| ERROR_DS_VERSION_CHECK_FAILURE | ERROR_NOT_SAFE_MODE_DRIVER |
ERROR_RANGE_NOT_FOUND
What ERROR_RANGE_NOT_FOUND means
Range-list APIs track occupied, free, mapped, or owned intervals. The failure means no entry covers the specified start and length under the requested matching rules.
Where it appears
- resource arbitration and device address ranges
- memory, file extent, or virtual-address bookkeeping
- drivers maintaining allowed or reserved intervals
Likely causes
- off-by-one or overflow in range endpoints
- the interval was already removed or split
- caller used a different coordinate space
- concurrent updates changed the list
Evidence to collect
- requested start, length, and inclusive/exclusive semantics
- complete range list at failure time
- operation history that inserted, split, or deleted ranges
- integer width and overflow checks
How to respond
Normalize endpoint arithmetic and retry only after refreshing the authoritative list. Do not fabricate a matching interval. Drivers should protect range mutations and log both hexadecimal boundaries and ownership.
Diagnostic interpretation
For this particular status, the decisive evidence is requested start, length, and inclusive/exclusive semantics, complete range list at failure time. Those details separate the documented condition from unrelated failures that happen to occur nearby.
Record the numeric code together with the symbolic name ERROR_RANGE_NOT_FOUND, the API or subsystem that produced it, and the first preceding failure. A later cleanup occurrence may describe a consequence instead of the initiating defect.
Example
A diagnostic trace records this result after an operation changes subsystem state. The result investigation should follow the first state-changing call, validate its resulting state, and classify later cleanup messages as secondary evidence.
Implementation guidance
Code handling this result should distinguish a terminal failure from a warning, progress indication, or request to repeat after a defined state change. When handling it, preserve handles and output fields only where the originating API explicitly keeps them valid. The path needs bounded retries and cleanup that tolerates partial initialization.
Validation after remediation
Repeat one controlled operation that previously produced this result. Verify both disappearance of the status and completion of the specific state transition described above. Adjacent messages around it must also be reviewed so a fallback is not mistaken for a complete repair.
References
Looking for a different code? Search another status or error code.