Disk I/O device error 0x8007045D during Windows repair, backup or setup

Fix it now

The storage device was asked to read or write and reported that it could not. Every code here is raised at the bottom of the storage stack, so the program showing it – Setup, a backup job, File Explorer – is not the fault. Work out which device failed, and copy the data off it before you repair anything.

Get-PhysicalDisk | Select-Object FriendlyName, MediaType, HealthStatus, OperationalStatus
Get-WinEvent -LogName System -MaxEvents 100 | Where-Object ProviderName -eq 'disk'
chkdsk X: /scan

1. Read the HealthStatus column. Microsoft documents four values – Healthy, Warning, Unhealthy and Unknown – and anything other than Healthy settles the question before you spend time on cables.
2. Read the System log entries. The disk driver names the device it could not reach, which tells you whether the source, the destination or the installation media is at fault.
3. If the data on that device is not backed up elsewhere, stop and image the drive to healthy storage now. Repair passes make a marginal drive worse.
4. Only once you have an image, repair the file system: chkdsk X: /f /r, or Repair-Volume -DriveLetter X -OfflineScanAndFix from PowerShell.
5. For an external drive, connect it directly to the machine rather than through a hub or dock, and swap the cable before concluding the drive is dead.

Microsoft’s own chkdsk reference notes that /r reads every sector and takes a considerable time, and that on an SSD it checks each sector’s physical integrity. That is exactly the load a dying drive cannot take, which is why the image comes first.

If the device now reads and writes cleanly you can stop here. If not, the next section explains which of the five codes you have and what each one actually says.

Why it happens

Windows layers storage requests. An application asks the file system, the file system asks the volume, the volume asks the disk driver, the driver asks the controller, and the controller asks the device. When the device cannot satisfy the request, the failure travels back up that chain and is translated into a Win32 error at the top. 0x8007045D is that translation for error 1117, ERROR_IO_DEVICE, whose published text is that the request could not be performed because of an I/O device error.

Because it comes from the bottom of the stack, the program reporting it is rarely relevant. Setup, a backup product, File Explorer and Windows Update all present a different message for the same underlying event. The information worth having is in the System log, where the disk driver records which device failed.

The companion codes are separate published errors rather than variations of the first, and they narrow the fault. 0x80070017 is ERROR_CRC: the data came back but did not match its checksum, so something between the platter and the buffer altered it. 0x8007001D is ERROR_WRITE_FAULT, the system cannot write to the specified device. 0x80070571 is ERROR_DISK_CORRUPT, the disk structure is corrupted and unreadable – a statement about the volume rather than the hardware. 0x8007001F is ERROR_GEN_FAILURE, published simply as a device attached to the system not functioning.

Full reference

Reading the five codes as a set

Only 0x80070571 is a statement about the volume. The other four are statements about the device, and no amount of file system repair changes what a device reports. That is the distinction that decides whether you reach for chkdsk or for a screwdriver.

Where the error appears, and what that usually means

The scan and repair commands, and what each costs you

Do not open with chkdsk /r on a drive you already suspect. Microsoft notes that it reads every sector, that on large drives the physical read speed alone makes it slow, and that on an SSD it checks every sector’s physical integrity. On a drive with a marginal head or a growing reallocation count that workload is often the last thing it does.

When the drive tests clean and the error persists

• Test the same drive on a different machine. If the error does not follow it, you have a host problem, not a drive problem.
• Check the power supply on a desktop with several drives. Marginal 12V rails produce intermittent device failures that look exactly like dying disks.
• On a laptop, check for a swollen battery pressing on the drive assembly or its connector.
• Look for a filter driver in the path. Backup, encryption and endpoint products all sit between the file system and the disk, and a failure inside one surfaces as a device error.
• If the fault only appears under sustained load, treat it as thermal until proven otherwise and watch the drive temperature during a long copy.

Getting data off a device that is still returning errors

1. Stop using it for anything else. Every additional read is a read the drive may not survive.
2. Attach it to a working machine as a secondary device, so nothing is trying to boot from it or index it.
3. Image it sector by sector with a tool that retries and skips, rather than copying files one at a time.
4. Mount the image and recover from that. Files that failed on the original often read cleanly from an image taken while the drive still cooperated.
5. Only then decide whether the original is worth a professional recovery attempt. That decision gets more expensive every time the drive is powered on.

Every code this article covers

Confirm the fix worked

1. Copy a large file to and from the device and confirm it completes without an error.
2. chkdsk X: /scan reports the volume clean.
3. Get-PhysicalDisk reports HealthStatus Healthy and OperationalStatus OK for that device.
4. The vendor diagnostic reports no uncorrectable errors and no growth in reallocated sectors.
5. After a day of normal use, the System log holds no new entries from the disk source for that device.

Questions people ask about this