| Previous | Next |
| ERROR_DISK_RECALIBRATE_FAILED | ERROR_DISK_RESET_FAILED |
ERROR_DISK_OPERATION_FAILED
While accessing the hard disk, a disk operation failed even after retries.
ERROR_DISK_OPERATION_FAILED is Win32 error 1127 (0x467). It records that a disk-level request did not succeed despite retry attempts. The definition does not name the exact operation or lower-level status, so the failing offset, command, device, and event-log context are essential.
Potential sources
- persistent media errors at a repeatable sector or logical block address
- controller, cable, enclosure, or transport failures that survive automatic retries
- firmware or driver faults in a physical or virtual disk path
- a disk removed or powered down while an operation was active
- legacy storage stacks that map several device statuses to the same code
The phrase “after retries” matters. Another immediate application retry can duplicate work already attempted by the driver and lengthen an outage without producing new evidence. First determine whether the storage stack is repeatedly hitting the same device condition.
Logging requirements
- read, write, flush, verify, or control operation and its exact byte range
- file path, volume GUID, disk number, partition, and backing virtual disk or array object
- duration and application retry count in addition to driver-level retries
- underlying protocol status, sense information, or vendor error when available
- correlated Disk, StorPort, Ntfs, ReFS, volmgr, or hypervisor events
Telemetry should distinguish a single object failure from a device-wide incident. Grouping by disk identity and LBA often reveals that many unrelated files are failing because they share one damaged region or path.
Response by workload type
- a read-only scanner can skip and report the unreadable range when partial results are acceptable
- a backup job should mark the backup incomplete and retain the source-device evidence
- a database should fail the I/O to its engine and use its own page, log, replica, or recovery logic
- a clustered service should fail over only if storage ownership and write ordering remain safe
- an installer should avoid rolling back by writing repeatedly to the same failing volume
There is no universal safe retry policy. Reads, idempotent metadata queries, buffered writes, and durable transactional writes have different ambiguity when the lower layer reports failure after retries.
Administrator actions
Check storage health and redundancy, verify backups, and inspect the controller or array before filesystem repair. If failures repeat on a physical device, plan replacement. If they follow a VM or storage path, involve the hypervisor or array layer rather than treating the guest filesystem as the only component.
Avoid clearing logs or rebooting before collecting the first failure sequence. A reboot can restore temporary access while removing evidence of resets, timeouts, and path failover.
Comparison with neighboring codes
ERROR_DISK_RECALIBRATE_FAILED names a failed recovery-positioning action. ERROR_DISK_RESET_FAILED identifies failure of a required controller reset. Error 1127 is the generic disk-operation result after retries, while ERROR_IO_DEVICE covers a wider range of device I/O.
Example
A database flush repeatedly fails with 1127, and the System log shows the same virtual disk timing out through one SAN path. Application retries only extend transaction latency. Failing over the storage path and then validating database consistency addresses the actual failure domain.
References
- Microsoft: System Error Codes (1000–1299)
- Microsoft: Troubleshooting data corruption and disk errors
Looking for a different code? Search another status or error code.