| Previous | Next |
| STATUS_PORT_UNREACHABLE | STATUS_CONNECTION_ABORTED |
STATUS_REQUEST_ABORTED
Abort is not the same as timeout, retry, or cancellation by the original caller
STATUS_REQUEST_ABORTED is used when a request is terminated by the owning stack or transport path before it can complete normally. The reason is API-specific, so the status should be interpreted with the device or protocol lifecycle. It is not automatically equivalent to STATUS_TIMEOUT, and code should not turn it into STATUS_RETRY without a documented recovery path.
Microsoft AV/C driver documentation tells callers to abort processing immediately on this status and explains that it can indicate a device was removed or is no longer available on the IEEE 1394 bus. Bluetooth SCO flush processing completes pending transfer IRPs with STATUS_REQUEST_ABORTED, while transfers already in progress complete according to their actual transfer result. RDBSS mini-redirector contracts also use the status for an aborted network request.
Capture the request ID, device/session state, remove or flush event, and whether the request was pending or already in progress. The distinction matters for resource ownership and upper-layer reporting. In a driver, complete or unwind the aborted operation exactly once and stop issuing dependent work. If reconnection or re-enumeration is supported, start a new operation against the new object state rather than blindly resubmitting the aborted request object.
What to inspect
- Correlate the abort with device removal, channel flush, session teardown, or provider cancellation events.
- Preserve whether the request was queued versus actively executing when the abort occurred.
- Recreate work against a valid new object/session only when the owning interface documents recovery.
References
- Microsoft: AVC_FUNCTION_COMMAND
- Microsoft: BRB_SCO_FLUSH_CHANNEL
- Microsoft: PMRX_CALLDOWN
- Microsoft: MRxQueryEaInfo
- Microsoft Open Specifications: NTSTATUS values
Looking for a different code? Search another status or error code.