| Previous | Next |
| ERROR_DISK_OPERATION_FAILED | ERROR_EOM_OVERFLOW |
ERROR_DISK_RESET_FAILED
While accessing the hard disk, a disk controller reset was needed, but even that failed.
ERROR_DISK_RESET_FAILED has value 1128 (0x468). The storage path judged that a controller or device reset was necessary to recover an I/O request, and the reset operation failed. This is stronger evidence of an unhealthy device path than an isolated application-level read error.
What can lead to a failed reset
- a controller or device no longer responds to commands
- transport, enclosure, cable, power, or firmware failure prevents reinitialization
- a virtual storage backend cannot reset or reopen its device object
- a driver deadlock or fault blocks completion of the reset sequence
- the hardware disappears during recovery or returns immediately to a failed state
On current hardware, the underlying action may be a bus reset, controller reset, namespace reset, path recovery, or virtual-device restart rather than the exact mechanism implied by older wording. Preserve the lower-level event text to learn which reset was attempted.
Immediate priorities
- protect data by stopping uncontrolled writes to the affected disk or path
- identify whether redundant paths, mirrors, or replicas remain healthy
- collect storage and system events before reboot or power cycling
- record every affected volume and workload, not only the first failing file
- escalate to the storage, hypervisor, or hardware owner with device identifiers
Repeated application retries are unlikely to repair a reset failure and may amplify queueing. A bounded retry can be appropriate after a confirmed path failover or device reappearance, but not while the controller remains unresponsive.
Evidence for root-cause analysis
- controller, port, target, LUN or namespace, disk number, and firmware versions
- I/O operation and LBA that triggered recovery
- reset start, reset completion, timeout, and subsequent device-enumeration events
- array, enclosure, host bus adapter, and hypervisor logs
- kernel dump or driver trace if reset handling appears blocked in software
A timeline is more valuable than a standalone code. It should show the original I/O timeout, retry sequence, reset request, reset failure, device removal or reappearance, and workload response.
Recovery
Fail over to a known-good path or replica when the storage design supports it. Otherwise place the workload in a safe stopped state and follow vendor recovery procedures. After access returns, validate filesystem and application consistency because completion of outstanding writes may be uncertain.
A power cycle can sometimes restore a wedged device, but it should be an operational recovery after evidence collection, not the entire diagnosis. Persistent or repeated 1128 results justify firmware review and hardware replacement planning.
Difference from ERROR_DISK_OPERATION_FAILED
ERROR_DISK_OPERATION_FAILED says a disk request failed after retries. ERROR_DISK_RESET_FAILED additionally says the controller-level recovery mechanism could not reset the path. That makes device availability and outstanding-write state especially important.
Example
A storage enclosure loses power on one controller. Guest writes time out, the host attempts a path reset, and the reset also fails with 1128. The correct response is storage-path failover and consistency verification; restarting the guest application alone cannot reestablish the missing controller.
References
- Microsoft: System Error Codes (1000–1299)
- Microsoft: Troubleshooting data corruption and disk errors
- Microsoft: Disk Event ID 154
Looking for a different code? Search another status or error code.