| Previous | Next |
| STATUS_DEVICE_OFF_LINE | STATUS_NO_MORE_EAS |
STATUS_DEVICE_BUSY
A busy device is present, but it cannot accept this request now
STATUS_DEVICE_BUSY is different from an absent or nonresponsive device. The device stack has a live target, but the requested operation conflicts with work or a resource that is already active. The useful question is therefore which lower-layer operation owns the device or serialization point, not whether the path name exists.
For storage hardware, preserve the completion information below the NTSTATUS conversion. Windows storage class drivers build storage requests and rely on lower port or bus layers to address the target; device-specific sense or transport status can explain whether the device is processing a command, changing state, or refusing new work. A generic retry loop can make the queue longer and hide the command that originally established the busy state.
Treat retry as a protocol decision. If the command set or device driver defines a wait, poll, or completion event, follow that mechanism. Reopening the file, changing ACLs, or rescanning hardware does not resolve a genuine device-level serialization conflict.
What to inspect
- The command, request type, target device identifier, and exact lower-layer completion status.
- Commands already outstanding on the same device and any reset, media-change, or long-running operation immediately before the failure.
- Whether the status is transient and clears when the documented operation completes, or repeats with an empty queue.
References
- Microsoft: Windows storage driver architecture
- Microsoft: Interpreting storage sense data
- INCITS T10: SCSI ASC/ASCQ assignments
- Microsoft Open Specifications: NTSTATUS values
Looking for a different code? Search another status or error code.