| Previous | Next |
| STATUS_CONVERT_TO_LARGE | STATUS_FOUND_OUT_OF_SCOPE |
STATUS_RETRY
Retry is part of the individual API contract, including when and how to try again
STATUS_RETRY is not a universal instruction to immediately call the same function in a tight loop. It says the request needs another attempt, but the returning API determines the retry timing, required state changes, and whether a retry count must be bounded. The caller must preserve that contract.
The D3COLD auxiliary-power callback is explicit: when it returns STATUS_RETRY, RetryInSeconds tells the driver how long to wait before the next request. Display miniport documentation gives other reasons, such as pending flips or the need to execute later at PASSIVE_LEVEL. RDBSS documentation also shows that some routines are not permitted to return STATUS_RETRY; if they need a retry loop, they must handle it internally. These examples demonstrate why the call site matters.
Log the retry reason and any provider-supplied delay or state flag. Set an upper bound where the contract requires caller-driven retries and keep the original failure if the limit is exceeded. Avoid retrying after cancellation, object teardown, or a permanent capability status. In asynchronous driver code, the retry path must also preserve IRP ownership and completion rules so the original request is completed exactly once.
What to inspect
- Read the failing routine's return contract for delay, level, or state requirements before retrying.
- Bound caller-controlled retries and record the attempt count plus the first failure.
- Recheck cancellation and object lifetime before resubmitting asynchronous work.
References
- Microsoft: D3COLD_REQUEST_AUX_POWER
- Microsoft: Registering an IoCompletion routine
- Microsoft: MRxCreate
- Microsoft: MRxCleanupFobx
- Microsoft Open Specifications: NTSTATUS values
Looking for a different code? Search another status or error code.