0x000008EA: NERR_BadReceive on Windows Network Share

What Actually Happens With 0x000008EA

You're on a Windows 10 or 11 machine, trying to access a network share — maybe a NAS, a Windows Server 2019 box, or another Windows 10 PC. You get the error: "The message was sent but not received." The full error code is 0x000008EA, which maps to NERR_BadReceive. What's actually happening here is that your machine sent a properly formed SMB (Server Message Block) request, but the receiving server examined the packet and decided it was garbage. That's not a dropped packet — that's an active rejection.

This usually happens in one of three scenarios, which I'll cover in order from most to least common. I've seen this on Windows 10 22H2, Windows 11 23H2, and Server 2019 mostly. The trigger is almost always a recent Windows update that changed SMB behavior, or a network driver update that mangled the TCP offload settings.

1. SMB Protocol Version Mismatch

The most common cause by a long shot. Windows 10 and 11 default to SMB 3.1.1. If the target device only speaks SMB 1.0 or 2.0, and your machine is configured to negotiate only high versions, the handshake fails. The receiver gets a packet it doesn't understand and returns NERR_BadReceive.

Where this bites you: Old NAS boxes (Synology DSM 5.x, older QNAPs), legacy Windows Server 2008 R2 shares, or any device where someone disabled SMB1 a while back but also didn't enable SMB2. I've also seen this with third-party SMB implementations like Samba 3.x on Linux.

The Fix: Force SMB 2.0 or 3.0 on the Client

You don't want to re-enable SMB1 — that's a security hole. Instead, tell your Windows client to try a lower version. Open PowerShell as admin:

Set-SmbClientConfiguration -RequestCompression $false
Set-SmbClientConfiguration -EnableLargeMtu $false
Set-SmbClientConfiguration -DisableSmb2 $false
Set-SmbClientConfiguration -EnableBandwidthThrottling $false
Set-SmbClientConfiguration -SMB2CreditsMin 32
Set-SmbClientConfiguration -SMB2CreditsMax 512

Then, on the client machine, we need to add a registry key to disable SMB 3.0 dialect negotiation. This forces it to SMB 2.1 or 2.0. Open Regedit and go to:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters

Create a DWORD named Smb2Disabled and set it to 0 (meaning SMB2 is enabled). Then create another DWORD named Smb3Disabled and set it to 1. Reboot.

The reason step 3 works: by disabling SMB3 negotiation, the client falls back to SMB 2.1, which most modern devices still support. The old device then receives a packet it can parse, and the error goes away.

If that still fails, you can try forcing SMB 1.0 temporarily — but only for testing. Open "Windows Features" and check "SMB 1.0/CIFS File Sharing Support". If the share works, you know it's a version issue. Then uncheck it and find a firmware update for the target device.

2. Corrupted Network Adapter Driver or TCP Offload

What's actually happening here is that your network adapter's hardware offload features are corrupting SMB packets. Modern adapters (Realtek, Intel, Killer) do TCP segmentation, checksum offloading, and large send offload in hardware. When the driver is buggy or out of date, the offload engine produces malformed frames. The receiving server sees an invalid SMB header and returns NERR_BadReceive.

Real-world trigger: I've seen this most often after a Windows Update that replaced a motherboard's Realtek driver with a generic Microsoft one. Happens on Gigabyte and ASUS boards a lot, especially with Realtek 2.5GbE chips.

The Fix: Disable Hardware Offloads and Update Driver

First, update the driver. Don't let Windows Update handle it. Go to the manufacturer's site (Realtek, Intel) and get the latest driver. For Realtek 2.5GbE, the driver version 10.68 or later fixed this issue. For Intel I219-V, version 12.19 or later.

If the error persists, disable TCP offload features. Open Device Manager, find your network adapter, right-click > Properties > Advanced tab. Look for these and set each to Disabled:

• Large Send Offload (LSO)
• TCP Checksum Offload (IPv4 and IPv6)
• UDP Checksum Offload
• VMQ (Virtual Machine Queue) if present

Then reboot. This forces all packet processing to happen in software via the Windows TCP/IP stack. It's slightly slower, but the packets come out correctly formatted. The share will start working.

If you want to confirm it was the offload: re-enable them one at a time and test. LSO is usually the culprit on Realtek chips.

3. Windows Firewall Blocking SMB with an Anomalous Rule

This one's less common but sneaky. A third-party firewall (Norton, McAfee, or even a misconfigured Windows Defender Firewall rule) can intercept the SMB packet, modify it, and then forward a corrupted version. The receiver sees a valid TCP connection but the SMB content is trash.

Real-world trigger: Happens after installing a VPN client (like NordVPN or ExpressVPN) that adds a firewall rule blocking inbound file sharing. The rule is meant to block incoming connections but sometimes blocks outbound SMB packets too, then re-injects them incorrectly.

The Fix: Audit and Reset Firewall Rules

Open Windows Defender Firewall with Advanced Security. Look for any outbound rules that reference File and Printer Sharing or NetBIOS. If you see a block rule, delete it. Also check for third-party firewall software — temporarily disable it. If the error stops, you've found the cause.

Then, run this PowerShell command to reset the Windows Firewall to defaults (this won't affect third-party software):

netsh advfirewall reset

This restores the default SMB allow rules. The reason this works: the default rules allow outbound SMB traffic on ports 445 and 139 without modification. No firewall software is mangling the packets anymore.

If you don't want to reset everything, run this to only reset the file sharing rules:

netsh advfirewall firewall set rule group="File and Printer Sharing" new enable=Yes

Quick-Reference Summary Table

Try them in that order. I'd bet money it's the SMB version mismatch 70% of the time. The offload issue is another 20%. Firewall stuff is rare but real.