The copy was going fine. Forty minutes into moving a video archive onto the external drive, or twenty percent into the nightly backup job, Windows stops with “Error 0x80070079: The semaphore timeout period has expired.” Retry the copy and it fails again — sometimes at the same file, sometimes earlier. Small files still copy fine. Large ones die partway. Or the error shows up in a backup log: the job that ran clean for two years now fails at 3 a.m. with the same message.

Few Windows errors are as widely encountered and as poorly explained as this one. The message itself sounds like nonsense — nobody outside a kernel debugger knows what a semaphore is or why it has a timeout — and most of the advice online treats it as a settings problem: disable power management, update drivers, change the network adapter offload settings. Sometimes that’s right. But there’s a specific, common, and time-sensitive cause that the settings advice completely misses: a drive in the early stages of failure, stalling so long on internal error recovery that Windows gives up waiting. When that’s the cause, every retry of the copy pushes a degrading drive harder — and this page exists to help you tell the difference before the retries finish the job.

What the error actually means

A semaphore, in Windows internals, is a signaling object — a way for one part of the system to wait until another part says “ready.” When Windows hands a read or write to a storage or network device, it waits on exactly this kind of signal for the operation to complete. The semaphore timeout error means precisely what it says: Windows waited for the device to finish an operation, the device didn’t respond within the allowed window, and Windows abandoned the wait.

So the error is not a description of a cause — it’s a description of a symptom: something in the path between your data and its destination stopped responding for a long time. The diagnostic question is what stalled. The candidates, roughly in the order we see them:

• A drive performing deep error recovery. When a hard drive hits a sector it can’t read or write cleanly, it doesn’t give up — it retries, recalibrates, re-reads, and retries again, for seconds at a time per sector. Desktop-class drives (which is what’s inside nearly every consumer external enclosure) will retry essentially forever, far past the patience of the operating system waiting on them. A drive developing bad sectors in a region your large file copy happens to cross will stall exactly long enough, exactly reproducibly, to generate this error — while still working fine for small files that land on healthy regions.
• An SMR drive buried by a sustained write. Many high-capacity consumer drives use Shingled Magnetic Recording, which handles bursts fine but can stall dramatically during long sustained writes while it rewrites shingled zones internally — the same behavior that gets SMR drives ejected from NAS arrays, as our Btrfs/Synology page describes. A healthy SMR drive can produce this timeout under a big enough copy. This is the benign-hardware version of the error — but you can’t tell it apart from the failing-drive version by the error message alone.
• A USB bridge or cable dropping out. External enclosures add a USB-to-SATA bridge between Windows and the drive, and bridges have their own failure modes: overheating during long transfers, marginal cables, undersupplied power on bus-powered drives. The transfer dies mid-flight; the drive itself may be fine.
• Network path problems, when the destination is a share or NAS: flaky Wi-Fi, a switch port renegotiating, adapter power management suspending the NIC mid-transfer, or offload features misbehaving. This is the version the settings advice online is actually written for.

Telling a failing drive apart from a settings problem

The stakes of the distinction are high — misreading a failing drive as a driver problem means hours of retried copies against dying hardware — so here’s the honest triage:

Signs pointing at the drive itself: the error involves a local (not network) disk; failures cluster around the same files or directory; the drive has become slower generally — folders take seconds to open, Explorer hangs when the drive is connected; you hear new sounds (clicking, buzzing, repeated spin-up attempts); the drive sometimes disappears from Explorer and comes back; or SMART data shows reallocated, pending, or uncorrectable sectors climbing. Any of these alongside the timeout error means treat it as a failing drive, full stop.

Signs pointing at the path instead: the destination is a network share and local copies to the same drive work; the error moved with a cable or port change; only one specific enclosure produces it while the bare drive tests clean; or the drive is a known SMR model and the error appears only deep into very large sustained writes, with the drive testing healthy otherwise.

The one test not to run: repeating the failed copy over and over to “see if it gets through this time.” If the cause is deep error recovery on degrading media, each pass re-stresses the same failing region. We regularly receive drives whose owners retried a large copy five or ten times over a weekend; the drive that produced a timeout on Friday is often unrecognizable by Monday.

If the data on the drive matters

When the triage points at the drive and the data on it is the only copy, the correct move is the same one that applies across every failing-hardware situation on our Windows recovery hub: stop using the drive, and get it imaged before anything else. Specifically:

• Stop the retries. Every pass over the failing region consumes some of whatever readable life the media has left.
• Don’t run chkdsk. A drive stalling on reads is a hardware problem; chkdsk answers with hours of intensive reads plus irreversible metadata writes. Our NTFS page covers why this combination destroys recoverable volumes.
• Don’t run consumer recovery or cloning software against it. Standard tools read sequentially and retry hard — exactly the access pattern a degrading drive tolerates worst. Lab imaging hardware works differently: it reads around trouble, harvests the healthy regions first, controls retry behavior per-region, and comes back for the difficult sectors last.
• Do note what the failure looked like — which files, how far in, what sounds — because it usefully narrows where on the platters the trouble lives.

If the triage points at the path instead — network issues, a bad cable, a healthy SMR drive under sustained load — the standard advice is fine: swap cables and ports, test the bare drive outside its enclosure, disable NIC power management for network copies, and break enormous transfers into smaller batches for SMR targets. No lab required, and we’ll happily tell you so on a free call rather than take in a drive that doesn’t need us.

The backup-job version

The enterprise variant of this error deserves its own mention: a nightly backup or replication job that starts failing with 0x80070079 in the logs. The triage is the same but the stakes compound quietly — a backup target drive entering failure means the safety copy is degrading, often unnoticed until a restore is needed. A backup job that begins timing out intermittently, then reliably, is following the classic trajectory of media failure, and the time to act is at “intermittently.” If the failing target holds the only current backup of something important, treat it with the same care as a failing primary: image first, then rebuild the backup chain on new hardware.

How the engagement works

Most semaphore-timeout cases that turn out to be failing external or internal drives are single-drive recoveries, and they fit our standard risk-free model: free evaluation, a flat-rate quote in writing before any work begins, payment only on successful recovery. If the situation is more complex — a failing backup target in a server, a network storage device behind the error — the consultation is still free, and any engineering terms are agreed in writing before work starts.