Fix Ethernet Not Working After Windows 11 Update

Your PC rebooted to finish installing a Windows 11 update, and now the Ethernet icon has a red X, or it shows connected with zero internet. The cable hasn't moved. The router hasn't changed. Something the update touched broke your wired connection, and figuring out fix ethernet not working after a Windows 11 update means finding out which of several unrelated things it actually did — not running every fix you find until one sticks.

I've had this happen on three different machines in the last year, and it was never the same cause twice. Once it was a driver Windows silently swapped in. Once it was the adapter itself sitting disabled in Device Manager. Once — on a work laptop tied to a switch that enforces port authentication — it was something a lot more specific and a lot less talked about. That's the one worth understanding before you touch anything else.

What a Windows update actually does to your Ethernet connection

A feature or cumulative update can touch your wired connection in four distinct ways, and they need four different fixes:

• It installs a new "compatible" driver over your working one, and the new driver doesn't play well with your specific NIC.
• It leaves the adapter disabled after the restart — this happens more than people expect, and it's the easiest thing to check first.
• It corrupts or resets part of the TCP/IP or Winsock stack, so the adapter shows connected but nothing actually resolves or routes.
• On networks that require 802.1X port authentication, an in-place upgrade can wipe the local policy files the Wired AutoConfig service depends on, so the machine physically connects but never authenticates onto the network.

None of these look different from the taskbar icon. You have to check for each one specifically. Here's the mapping I use before I touch a single setting.

Symptom, check, and fix — mapped together

Symptom	Confirming check	Fix
Ethernet shows "Not connected," red X on the icon	Device Manager > Network adapters — adapter greyed out or has a down arrow	Re-enable the adapter
Yellow warning triangle on the adapter in Device Manager	Adapter Properties > General tab shows a device status error	Roll back or reinstall the driver
"Connected, no internet" with a valid link light	ipconfig /all shows an APIPA address (169.254.x.x) or missing default gateway	Reset Winsock/TCP-IP stack, then check DHCP
Domain/managed PC, wired connection times out or drops to a guest VLAN	Event Viewer > Applications and Services Logs > Microsoft > Windows > Wired-AutoConfig shows authentication failures after an in-place upgrade	Force a Group Policy update over a working connection, restore dot3svc policy
Adapter present, connects, then drops every few minutes	Adapter Properties > Advanced > Large Send Offload set to Enabled on a driver build known to mishandle it	Disable LSO v2 (IPv4 and IPv6)

Work down that table in order — checks first, invasive stuff last. Don't jump to a driver reinstall because a forum thread told you to; confirm the yellow triangle first.

Rule out the boring cause before the interesting one

Before you open Device Manager at all: unplug the cable, reseat it firmly on both ends, and check the link and activity lights on the port. A cable that's been stepped on or crimped under a desk leg will produce the exact same "connected, no internet" symptom as a corrupted stack, and I've wasted twenty minutes on registry edits before finally swapping the cable and watching it work instantly. If you have a spare cable, use it. If Wi-Fi works fine on the same machine, that tells you the update didn't wreck general networking — it's specific to the wired path, which points you back toward driver or 802.1X causes rather than DNS or Winsock.

Check whether the adapter got disabled

Press Windows + R, type ncpa.cpl, and press Enter. If the Ethernet adapter tile is greyed out, right-click it and choose Enable. This sounds too simple to be a real fix, but updates that touch network drivers sometimes leave the adapter in a disabled state after the mandatory restart, and I've seen it happen on both Intel and Realtek onboard NICs. It takes ten seconds to check and rule out, so do it before anything else on this list.

Confirm a driver conflict, then roll back or reinstall

Open Device Manager (Windows + X, then Device Manager), expand Network adapters, and look at your Ethernet controller. A yellow warning icon confirms a driver-level problem — don't guess at this, look for the icon. Right-click the adapter, choose Properties, then the Driver tab.

If Roll Back Driver is available (not greyed out), use it. Windows only keeps the previous driver package for a limited window after an update, so this option disappears eventually — if it's greyed out, Windows has already discarded the old driver and you'll need to reinstall instead.

To reinstall clean: still in the Driver tab, click Uninstall Device, check "Attempt to remove the driver for this device" only if you have a replacement ready, then restart. Windows will usually redetect the adapter and pull a driver automatically. If it doesn't, or if you're on a laptop with a vendor-specific chipset, go to the manufacturer's support page — Dell, HP, Lenovo, ASUS — and download the LAN driver by your exact model number rather than trusting a generic Windows Update driver. I've had generic drivers install fine and still misbehave on laptops with proprietary power-management hooks in the vendor driver.

The 802.1X case: when the connection authenticates but never gets on the network

This one's specific enough that most general troubleshooting guides don't mention it, and it only applies if your Ethernet port is on a network that enforces IEEE 802.1X authentication — typical in corporate and campus environments, not home networks. Windows handles this through the Wired AutoConfig service (dot3svc), which reads policy files that tell it how to authenticate to the switch.

Reports from system administrators on community forums and tech outlets describe in-place Windows 11 upgrades — including 23H2 moving to 24H2 or 25H2 — emptying the policy folder these authentication settings live in, leaving the machine physically connected to the switch but unable to authenticate. Microsoft has not listed this as a known issue on its official Windows release health dashboard, so treat it as a documented community pattern rather than a confirmed, acknowledged bug.

If you manage machines on an 802.1X wired network and a PC goes dark on Ethernet immediately after an in-place feature update — while Wi-Fi on the same building still works, or a colleague's machine on the same switch port works fine — that's the pattern to check for. The practical fix: get the machine on a network path that isn't gated by 802.1X (a guest Wi-Fi network, a non-authenticated port, or physically at the domain controller), then run gpupdate /force as an administrator to have it re-pull the wired policy from Group Policy. For fleets, back up the policy folder before running upgrades and add a post-upgrade step to reapply the 802.1X profile via Intune or GPO rather than discovering the gap machine by machine.

If your Ethernet isn't on a managed 802.1X network — most home setups aren't — skip this section entirely and move to the stack reset below.

Reset the TCP/IP stack when the adapter connects but nothing resolves

This is the right move when ipconfig /all shows a self-assigned 169.254.x.x address, no default gateway, or a gateway that doesn't match your router's actual LAN address. Open Command Prompt as administrator and run these one at a time:

netsh winsock reset
netsh int ip reset
ipconfig /release
ipconfig /renew
ipconfig /flushdns

Expect output like Winsock reset completed successfully. You must restart the computer in order to complete the reset. after the first command, and similar confirmation lines after the second. Restart before testing — the Winsock reset genuinely doesn't take effect until reboot, and testing before that will make you think it failed. This resets the Windows Sockets catalog and rewrites the TCP/IP registry keys to their defaults; it doesn't touch your driver or saved Wi-Fi credentials.

Large Send Offload — a quieter cause of intermittent drops

If your connection comes up after an update but drops every few minutes instead of staying fully dead, check Large Send Offload before assuming it's a cable. In Device Manager, open the adapter's Properties, go to the Advanced tab, and look for Large Send Offload V2 (IPv4) and (IPv6) in the property list. Set both to Disabled and test. You can do the same from an elevated PowerShell prompt with Disable-NetAdapterLso -Name "Ethernet" -IncludeHidden, swapping "Ethernet" for whatever your adapter is actually named in Settings > Network & internet > Advanced network settings. This is a real, adapter-level performance feature, not a placebo setting — it's just one some driver builds handle badly, and disabling it costs you a small amount of CPU offload in exchange for stability.

Network reset — the last resort, not the first click

If you've confirmed the adapter is enabled, the driver is current, and the stack reset didn't help, go to Settings > Network & internet > Advanced network settings > Network reset. This removes every network adapter and reinstalls them with default settings, which also wipes saved Wi-Fi passwords, VPN configurations, and any static IP or custom DNS you'd set. Write those down first. It's effective specifically because it's total — it doesn't diagnose anything, it just starts over. That's exactly why it belongs last: if a targeted fix above already solved it, resetting everything just means redoing configuration you didn't need to lose.

What I would not do

• Uninstall the Windows update blind before checking Device Manager for five minutes — most of the time the update didn't touch the driver at all, and rolling back means losing whatever security fixes shipped with it.
• Run a registry edit you found in a forum post without reading what the key actually controls — the WcmSvc DependOnService edits circulating for this issue can affect service startup order for other components if applied on a system that isn't actually hitting that specific failure.
• Reinstall Windows over a network problem. I've seen this suggested as a first step and it's a huge overreaction to something that's almost always a driver or config issue.
• Buy a new network card before testing with a different cable. Physical layer problems mimic software problems constantly, and a $3 cable swap rules out a $40 mistake.

Quick checklist before you close this out

• Cable reseated and tested with a known-good alternative
• Adapter confirmed enabled in ncpa.cpl
• Device Manager checked for a yellow warning icon
• Driver rolled back or reinstalled from the vendor site if needed
• On a managed 802.1X network — policy re-pushed via gpupdate /force if applicable
• Winsock/TCP-IP stack reset and rebooted before retesting
• Large Send Offload disabled if drops are intermittent rather than total
• Network reset held in reserve, not used first

For the full official troubleshooting sequence Microsoft maintains for connection problems, including the network reset steps, see Microsoft's connection troubleshooting guide.