Fix STATUS_NDIS_OFFLOAD_PATH_REJECTED (0XC0231013) Fast

Cause 1: Stale Offload State After Driver Update or Failover

I've seen this error pop up right after a NIC driver update or a live migration in Hyper-V. The offload engine on the adapter still holds a stale path object, and the OS rejects it because the underlying state doesn't match. The fastest fix is to force the adapter to reset its offload state without rebooting the whole box.

1. Open PowerShell as Administrator.
2. Run Get-NetAdapter | Where-Object {$_.Status -eq 'Up'} to list active adapters.
3. Note the Name of the adapter showing the error (often the one handling VM traffic or a team).
4. Restart the adapter: Restart-NetAdapter -Name "Ethernet" -Confirm:$false (replace "Ethernet" with your adapter name).

If that doesn't clear it, disable and re-enable TCP offload on the adapter:

Disable-NetAdapterChecksumOffload -Name "Ethernet" -TcpIPv4 -TcpIPv6
Enable-NetAdapterChecksumOffload -Name "Ethernet" -TcpIPv4 -TcpIPv6

This resets the offload engine's state machine. It worked for a client who saw the error after a Windows Server 2019 cumulative update broke their Broadcom adapter's offload. If you're on a VM, also try a quick shutdown and start—not a restart—to force the hypervisor to renegotiate offload.

Cause 2: TCP Chimney Offload Still Enabled

Old TCP Chimney Offload is a frequent culprit, especially on legacy drivers or after upgrading from Windows Server 2008/2012. It's been deprecated since Windows 8/Server 2012, but some third-party drivers still attempt it. The error shows up when the TCP stack tries to offload a connection and the NIC refuses—often because the chimney state is half-broken.

Turn it off globally—you don't need it, and it rarely improves performance on modern hardware.

netsh int tcp set global chimney=disabled
netsh int tcp set global rss=enabled

Then reboot the server or restart the NIC. I've also seen cases where netsh int tcp set global autotuninglevel=normal helps, but don't touch that unless you're also seeing throughput issues.

If you're in a Hyper-V environment, also check the virtual switch settings. Sometimes the vSwitch inherits offload settings from the physical NIC. You can force a refresh by disabling and re-enabling the vSwitch with:

Get-VMSwitch | Update-VMSwitch

That command isn't native—wait, I got excited. The real cmdlet is Restart-VMSwitch but that's only in newer builds. For older ones, you'll need to disable the adapter in the host's NIC teaming, if any. Keep it simple: just disable and re-enable the physical NIC that the vSwitch binds to.

Cause 3: Third-Party Security or VPN Software Interfering

The sneaky one. I've debugged this error on machines where the NIC was fine, but a web filter or VPN client injected an LSP (Layered Service Provider) that intercepts offload calls. These hooks corrupt the offload path object, and the NDIS driver returns 0XC0231013. You won't see it in Event Viewer—it's a silent killer.

Check for known offenders like older versions of Cisco AnyConnect, Check Point Endpoint Security, or even some anti-cheat engines. Here's the test:

• Temporarily uninstall or disable the third-party network filter (don't just disable the service—use the app's own uninstaller or disable the network adapter binding).
• Restart the machine.
• If the error disappears, reinstall the latest version of the software or configure it to bypass your internal network.

To see what's bound to your NIC, run Get-NetAdapterBinding -Name "Ethernet". Look for entries that mention the vendor name. Disable them one by one, restarting the adapter each time, until the error clears. It's tedious, but it pinpoints the culprit.

Also, check if you have any legacy protocol like IPX or NetBIOS that's not needed. Unbind them—they add no value and can confuse the offload engine.

Quick-Reference Summary

Start with the adapter restart—it's the least invasive. If that fails, kill chimney. Only then start monkeying with third-party software. Don't skip straight to reinstalling drivers; that's a waste of time when the above steps resolve 90% of cases. And if you're on a VM, remember to do a full stop/start, not just a restart, to clear the hypervisor's offload cache.