Runtime Error 57: “Device I/O error,” explained and fixed

Error 57, “Device I/O error”, is one of the few VBA errors that usually does mean the environment: a storage device or peripheral failed to complete a read or write. The mapped network drive dropped, the USB device was removed, the disk has a bad sector, or the printer went offline during output. Code cannot fix a failing device, but good code decides whether the failure is a clean message or a lost file, so both angles matter here.

For people who just run the program

  1. Check the device is still there. Open the drive or folder in File Explorer. If a network or USB drive has vanished or asks to reconnect, that is the whole story.
  2. Do not keep retrying against a failing disk. Repeated attempts on a dying drive can make recovery worse. Copy anything readable off it first, then diagnose.
  3. Try a different location. Save or read from a local folder instead. Success locally confirms the original device, not the program or the data.
  4. Report which device and when it happens. “Fails on the shared drive after lunch” points at network power settings or a server restart, and that pattern is the fix.

For people who write the code

  1. Treat 57 as retryable once, then fatal. A single retry after a short pause survives a network hiccup; beyond that, report the device and stop cleanly rather than looping against failing hardware.
    2. On Error GoTo IoFail
WriteChunk fn, data
' ...
IoFail:
    If Err.Number = 57 And retries < 1 Then
        retries = retries + 1
        Resume          ' one retry for a transient drop
    End If
  2. Write to a temporary file, then rename. Building output directly on a flaky destination leaves a corrupt half-file when I/O fails mid-write. Writing locally and copying over at the end keeps the failure atomic.
  3. Log the device path with the error. Error 57 without its target path is useless in a bug report. Err context plus the resolved drive letter or UNC path separates “this server” from “all storage.”
A device I/O error on a local disk is a hardware warning, not an annoyance. If error 57 appears against the machine's own drive with increasing frequency, back up immediately and check the disk's health. Software workarounds on failing media lose data.

If it still happens

If the device tests healthy and every other program uses it without trouble, check the access pattern: very old code addressing a printer or port by a legacy device name (LPT1, COM1) can produce I/O failures on systems where that name maps to nothing. Redirect the output to a named modern device and retest.

Common questions

Is error 57 a bug in the program? Usually not. It reports that the device failed to complete an operation. The program's responsibility is limited to handling it gracefully: retrying once, preserving the data, and naming the device in its message.

Why does error 57 happen over the network but not locally? Because network storage adds failure modes local disks do not have: dropped connections, server reboots, sleeping adapters, and expired sessions all interrupt I/O mid-operation.

Related errors

Runtime Error 68 · Runtime Error 71 · Runtime Error 61