| Previous | Next |
| ERROR_MEDIA_CHANGED | ERROR_NO_MEDIA_IN_DRIVE |
ERROR_BUS_RESET
the i/o bus was reset.
ERROR_BUS_RESET means that a storage or device bus reset interrupted the assumptions of the current I/O operation. In this case, the decisive context is SCSI, SAS, USB, Fibre Channel, virtual storage, and other device stacks, together with device instance/path, controller, transport, reset timestamp, and affected commands.
Where the result appears
- SCSI, SAS, USB, Fibre Channel, virtual storage, and other device stacks.
- device recovery after timeout or transport error.
- path failover and controller reset.
- hot-plug, power, firmware, or virtualization events.
Typical causes
- a device or command timed out and the stack reset the bus to recover.
- controller, cable, power, firmware, or transport instability.
- another initiator or management action triggered a reset.
- virtualization or multipath failover recreated the device path.
Evidence to collect
- device instance/path, controller, transport, reset timestamp, and affected commands.
- storage, kernel, multipath, hypervisor, and hardware event logs.
- timeouts or errors immediately preceding the reset.
- firmware/driver versions, topology, power state, and recurrence pattern.
For this condition, begin the investigation with device instance/path, controller, transport, reset timestamp, and affected commands. Correlate it with storage, kernel, multipath, hypervisor, and hardware event logs and check whether a device or command timed out and the stack reset the bus to recover. Capture the original this result immediately after the failing call so later cleanup does not replace the thread-local error value.
Handling and recovery
Assume in-flight requests may need revalidation. Reopen or re-query device state according to the API contract, and retry only operations documented as safe and idempotent. Repeated resets are a reliability incident requiring transport and hardware investigation, not an application-level retry problem.
Any retry policy for this Win32 error should be tied to evidence that controller, cable, power, firmware, or transport instability has changed. Before another attempt, verify timeouts or errors immediately preceding the reset. If virtualization or multipath failover recreated the device path still applies, stop the retry sequence and preserve the first diagnostic event.
Common misinterpretation
A bus reset is broader than a single command failure and does not automatically mean the target device itself is defective.
Guidance for developers
When surfacing this result through another layer, retain its Win32 domain, numeric value, and the operation described by device recovery after timeout or transport error. A useful telemetry record also includes firmware/driver versions, topology, power state, and recurrence pattern. For a-related handling, decisions must use the numeric value and documented API contract rather than localized wording.
A focused test should reproduce the condition in which another initiator or management action triggered a reset, assert this result, and confirm that the program releases resources associated with path failover and controller reset. The recovery test should also verify that device instance/path, controller, transport, reset timestamp, and affected commands is refreshed before the operation resumes.
References
Looking for a different code? Search another status or error code.