| Previous | Next |
| STATUS_TOO_MANY_OPENED_FILES | STATUS_CANNOT_DELETE |
STATUS_CANCELLED
Meaning and context of STATUS_CANCELLED
A device's in-progress I/O operation (such as a request to read several blocks from a disk) can be canceled by an application, the system, or a driver. If a device's I/O operation is canceled, the I/O manager attempts to cancel all unprocessed I/O requests that are associated with the I/O operation. The device's drivers can register to be notified when the I/O manager attempts to cancel I/O requests, and the drivers can cancel the requests that they own by completing them with a completion status of STATUS_CANCELLED.
An user mode application can use CancelIo or CancelIoEx functions of Win32 API, to cancel pensing request. For more details, see CancelIo
Driver routines that change the state of cancelable IRPs, including all routines that might complete an IRP with STATUS_CANCELLED, must acquire and release the system cancel spin lock according to the guidelines in this section.
Drivers in which IRPs might remain queued for an indefinite interval (so a user could cancel a previously submitted I/O request) must have one or more Cancel routines to complete user-canceled I/O requests. For example, keyboard, mouse, parallel, serial, and sound device drivers (or drivers layered over them) and file system drivers should have Cancel routines. The cancellation process begins when either the system or a driver calls IoCancelIrp. This routine is called for each IRP that is associated with the thread that has not yet fully completed. The system cancels unprocessed IRPs if the thread that initiated the I/O request exits. Drivers can cancel only IRPs that they have created (see Creating IRPs for Lower-Level Drivers.)
Native status interpretation for STATUS_CANCELLED
STATUS_CANCELLED is 0xC0000120, an NTSTATUS error value. AllStat describes it as “The I/O request was canceled.”. For STATUS_CANCELLED, the first useful question is which native API, IRP, protocol operation, or subsystem in the kernel, native API, or subsystem that returned the status produced that status.
Debugging sequence for STATUS_CANCELLED
- Preserve STATUS_CANCELLED before RtlNtStatusToDosError, HRESULT conversion, exception translation, or provider-specific remapping removes information.
- Log the operation associated with cancelled, the object or handle type, process and thread identity, and the state transition immediately before the return.
- When user mode receives STATUS_CANCELLED, capture both the native status and the final Win32/COM error so the translation boundary remains visible.
Recovery considerations for STATUS_CANCELLED
A retry is appropriate only after the owner of STATUS_CANCELLED has changed the state described by “The I/O request was canceled.”, or when its contract explicitly marks the status as transient. For STATUS_CANCELLED, if the value reports corruption, invalid format, access policy, or a lifecycle mismatch, preserve evidence and correct that cause before repeating the request.
Looking for a different code? Search another status or error code.