What causes error 0x80070079?

A stalled transfer: the link worked but paused long enough to time out mid-copy. Common causes are a damaged or marginal Ethernet cable, network-adapter power management suspending the NIC, Large Send Offload or other offload settings, a port stuck at 100 Mbps or half-duplex, antivirus scanning files as they are written, or an outdated network driver.

How do I fix the semaphore timeout error?

Work through it in order: swap the Ethernet cable and try a different switch port, disable "Allow the computer to turn off this device to save power" on the adapter (both machines), check the link is at full gigabit with Get-NetAdapter, disable Large Send Offload in the adapter's Advanced settings, update the NIC driver from the manufacturer, and temporarily disable antivirus to rule it out.

Why does the error only happen on large files?

Because a long transfer gives the weak link more time to stall — a small file finishes before the marginal cable or power-saving hiccup can interrupt it. Tools that resume interrupted transfers, like Oxolan, continue from where they stopped instead of failing, so the same weak link slows the copy rather than killing it partway.

Error 0x80070079 — The Semaphore Timeout Period Has Expired (Fix)

What This Error Means

You start copying a file across the network and partway through Windows stops with:

Error 0x80070079: The semaphore timeout period has expired.

Unlike the "network name" errors, 0x80070079 usually means the connection was working and then a transfer stalled long enough for Windows to give up. It is rarely a permissions or share-configuration problem — it is almost always something physical or driver-level interrupting the data stream: a flaky cable, a network adapter power-saving or offload setting, a driver, or antivirus stepping in mid-copy.

Large files trigger it most, because a long transfer gives the weak link more chances to stall. It is closely related to mapped drives disconnecting and error 0x80070040.

Root Cause 1 — Network Adapter Power Management

Windows suspends network adapters to save power by default, even on desktops. Mid-transfer, that suspension stalls the stream and triggers the timeout.

Fix (do this on both machines): Device Manager → Network adapters → right-click your adapter → Properties → Power Management → uncheck "Allow the computer to turn off this device to save power."

Root Cause 2 — A Marginal Cable or Port

A cable that is damaged, too long, or barely passing can carry small transfers fine and fail on sustained ones. This is the single most common physical cause.

Fix:

Swap the Ethernet cable end to end — this alone resolves a large share of cases.
Try a different port on the switch or router.
Confirm the link negotiated at full speed (see the check in root cause 4).

Root Cause 3 — Large Send Offload / Offload Settings

NIC "offload" features (Large Send Offload, Checksum Offload, Jumbo Frames set wrong) can corrupt or stall sustained transfers on some driver/hardware combinations.

Fix (on the machine seeing the error): Device Manager → your adapter → Properties → Advanced tab. Set Large Send Offload V2 (IPv4) and (IPv6) to Disabled. If Jumbo Frames is enabled but your switch does not support it, set it back to Disabled (1514 bytes). Reboot and retest.

Root Cause 4 — Speed/Duplex Mismatch or a 100 Mbps Link

A port stuck at half-duplex or negotiated down to 100 Mbps produces stalls and errors on large copies.

Check the link speed (PowerShell):

Get-NetAdapter | Select-Object Name, LinkSpeed, Status

If a gigabit adapter shows 100 Mbps, suspect the cable (root cause 2) or the switch port. In the adapter's Advanced tab, leave Speed & Duplex on Auto Negotiation unless you have a specific reason not to.

Root Cause 5 — Antivirus or Backup Software Scanning the Stream

Real-time antivirus or a backup agent scanning files as they are written can pause a transfer long enough to time out.

Fix: Temporarily disable third-party real-time protection and retry. If that resolves it, add an exclusion for the destination folder rather than leaving protection off.

Root Cause 6 — An Outdated Network Driver

A stale or generic NIC driver is a frequent culprit, especially after a Windows feature update swapped in its own driver.

Fix: Get the current driver from the adapter or motherboard manufacturer (Intel, Realtek, etc.) rather than relying on Windows Update's generic version, install it, and reboot.

Step-by-Step Diagnostic

Swap the Ethernet cable and try a different switch port (fastest thing to rule out).
Disable adapter power management on both machines.
Check Get-NetAdapter link speed — fix anything not at full gigabit.
Disable Large Send Offload in the adapter's Advanced settings.
Update the NIC driver from the manufacturer.
Temporarily disable antivirus to confirm it is not interrupting the copy.

If the transfer is also just slow rather than failing, work through the slow local transfer guide as well — the causes overlap.

Why a Different Tool Avoids It

0x80070079 is Windows' SMB copy engine giving up when the underlying link stalls, and SMB restarts an interrupted copy from zero. Transfer tools built for large files handle this differently: Oxolan streams in verified chunks and resumes after an interruption instead of failing, so a marginal cable or a power-management hiccup slows a transfer rather than killing it at 80%.