Wi-Fi connects but has no Internet after an update: reinstall the adapter driver

Windows 10/11 may associate with a Wi-Fi access point and show the expected network name while browsers and other applications cannot reach the Internet. The failure can begin after a Windows or driver update. In the evidence behind this writeup, reinstalling the wireless-adapter driver restored connectivity; one case also flushed the DNS cache.

An associated Wi-Fi radio is only the first link in the path. The same symptom can be caused by the router, ISP, DHCP, DNS, a VPN or security filter, a proxy, a captive portal, or a Windows driver. This procedure proves that the access point and wider network work, records the Windows address/gateway/DNS state, and prepares a replacement driver before removing the active adapter.

Searchable Windows error codes and exact messages

An IPv4 address beginning with 169.254 is an observed automatic private address, not an error code. It supports a DHCP-path problem when the network is supposed to issue a different address.

Use this procedure when:

• Windows 10 or Windows 11 shows an association to the intended Wi-Fi network;
• the failure started after a Windows update, driver update, OEM utility update, or unexplained driver replacement;
• another device can use the same access point and Internet connection at the same time;
• the affected computer can use a different network or the evidence otherwise isolates the problem to that computer;
• the exact wireless-adapter model is identified; and
• an appropriate OEM/computer-manufacturer driver package is downloaded before uninstalling the current driver.

The driver diagnosis is strongest when the adapter's driver version/date changed with the failure and rolling back or reinstalling that driver restores gateway, DNS, and Internet access.

Do not use this as the first procedure when every device on the network is offline, the router cannot reach its ISP, the Wi-Fi password is rejected, the SSID is absent, airplane mode is on, or the wireless adapter is disabled by a physical switch or firmware setting.

It also does not apply when:

• the computer is behind a captive portal that has not been accepted;
• only one website or application fails;
• a manually configured static address, gateway, proxy, or DNS server is intentional and its owner has not approved a change;
• the computer is domain-managed, uses enterprise 802.1X, or has an administered VPN/endpoint filter;
• Device Manager does not enumerate the adapter after shutdown and the OEM diagnostic also cannot detect it;
• the problem occurs only far from the access point or on one radio band; or
• Ethernet and Wi-Fi fail identically while a VPN, proxy, firewall, or DNS filter is active.

Do not remove a network driver from a remote-only computer unless someone has local access and a tested recovery path.

The exact update package that replaced the driver, the router firmware version, and the original DNS-cache entry may remain unknown.

The following may not remain unknown before driver removal:

• the exact adapter name, hardware IDs, driver provider, version, and date;
• whether other devices can use the same network;
• the affected computer's IPv4 address, default gateway, DHCP state, and DNS servers;
• whether the failure is gateway reachability, public-IP reachability, DNS resolution, or application-specific;
• whether a VPN, proxy, virtual adapter, or endpoint filter is present;
• the path to an offline copy of the correct replacement driver; and
• whether local access will remain available after the adapter is removed.

• Local administrator access
• Local keyboard/display access or another tested management path that does not depend on the Wi-Fi adapter
• The exact computer model or wireless-adapter hardware IDs
• A replacement driver from the computer or adapter manufacturer, saved locally before removal
• The current Wi-Fi password or another authorized reconnection method
• A second device for comparing the access point/Internet connection
• A current backup of important files
• A place to record commands, driver versions, and test results

When possible, connect temporary Ethernet before driver removal. Do not assume Windows Update can fetch a driver while the only network adapter is offline.

1. Restart the computer once. Confirm that the same problem returns before changing a driver.

2. Test the same Wi-Fi network from another phone or computer. If it also lacks Internet, stop and diagnose the router/ISP.

3. On the affected computer, disconnect any VPN using its normal control. Record the VPN name and state; do not uninstall it.

4. Open Settings > Network & internet > Proxy and record whether a manual proxy is enabled. Do not disable an organization-managed proxy.

5. Open an elevated Command Prompt and create an evidence folder:

   md "%USERPROFILE%\Desktop\WiFi-before"
   ipconfig /all > "%USERPROFILE%\Desktop\WiFi-before\ipconfig-all.txt"
   route print -4 > "%USERPROFILE%\Desktop\WiFi-before\route-print-4.txt"
   netsh wlan show interfaces > "%USERPROFILE%\Desktop\WiFi-before\wlan-interfaces.txt"
   netsh wlan show drivers > "%USERPROFILE%\Desktop\WiFi-before\wlan-drivers.txt"
   netsh winhttp show proxy > "%USERPROFILE%\Desktop\WiFi-before\winhttp-proxy.txt"
   

6. Generate the Windows wireless report:

   netsh wlan show wlanreport
   

   Record the output path. Do not publish the report without redacting SSIDs, adapter addresses, user names, and other local identifiers.

7. Open Device Manager with:

   devmgmt.msc
   

8. Expand Network adapters, open the exact Wi-Fi adapter, and record:

   • General > Device status;
   • Driver > Driver Provider, Driver Date, Driver Version;
   • whether Roll Back Driver is available; and
   • Details > Hardware Ids.

9. Download the exact-model OEM driver. Verify that the package explicitly supports the hardware/Windows version. Save it outside temporary/download-cache folders and confirm it opens or extracts before removing anything.

1. In the recorded netsh wlan show interfaces output, confirm that State is connected and that the SSID is the intended network. If it is disconnected, this article's connected/no-Internet premise is not met.

2. In ipconfig /all, locate only the Wi-Fi adapter and record:

   • DHCP Enabled;
   • IPv4 address and subnet mask;
   • default gateway;
   • DHCP server; and
   • DNS servers.

3. If the network is supposed to use DHCP but the adapter has a 169.254.x.x address and no usable default gateway, the immediate failure is address acquisition. Confirm that another device receives a normal address from the same access point. Driver reinstall remains a candidate, but DHCP/router filtering and network policy must remain in scope.

4. Ping the recorded default gateway, not a guessed router address:

   ping <default-gateway>
   

5. Interpret the result:

   • Replies prove basic local IP reachability at that moment.
   • Destination host unreachable must be recorded with the sender address. An unreachable message from the affected computer suggests no usable local route/neighbor path; one from a router identifies a later route.
   • Request timed out alone is inconclusive because some devices ignore ICMP.

6. If the gateway responds, test name resolution:

   nslookup www.microsoft.com
   

   Record the responding DNS server and answer. If name lookup fails, test IP-layer reachability separately rather than browsing to a raw IP, because HTTPS certificates, SNI, and host routing can make a reachable server look unavailable in a browser. For example, from PowerShell use Test-NetConnection <known-public-IP> -Port 443. Successful IP/port reachability while nslookup fails supports a DNS-path problem; it does not by itself identify which DNS component is wrong.

7. Check whether the issue follows the Windows computer. Connect it briefly to an authorized phone hotspot or another known-good network. If Internet access works there, the driver may still have a compatibility problem with the original access point, but a router profile/band/security interaction remains possible. Do not call it a general driver failure yet.

8. Review Device Manager. If the exact adapter currently shows Code 10, 31, 43, or 56, it is not operating normally and generally cannot be the same currently associated interface. Stop this connected/no-Internet procedure and route to the adapter-start/device-setup branch for that exact code. A code recorded before a driver change can remain useful chronology only if it has cleared and the adapter now associates. A status of This device is working properly does not eliminate a functional driver defect.

9. If Roll Back Driver is enabled and the recorded driver date/version changed at the same time as the failure, use Resolution Branch A first. It is more reversible than removal.

10. If rollback is unavailable, ordinary network comparisons isolate the failure to the PC, and the replacement OEM package is ready, use Branch B.

11. Stop before driver changes when the fault is limited to DNS, a proxy, VPN, captive portal, manually configured addressing, organization policy, or an access point that fails for multiple devices.

Branch A — Roll back a recently replaced Wi-Fi driver

1. In Device Manager, open the exact Wi-Fi adapter's Properties > Driver tab.

2. Confirm the provider/version/date match the recorded adapter.

3. Select Roll Back Driver. Choose the truthful reason and complete the prompt.

4. Restart Windows even if Device Manager does not demand it.

5. Reconnect to the intended Wi-Fi network and repeat the gateway and DNS tests in section 7.

6. If connectivity returns, proceed to verification. Do not immediately reinstall the failing driver through a third-party driver updater.

Branch B — Uninstall the adapter device and let Windows re-enumerate it

1. Confirm that the OEM driver installer is saved locally and that local access will remain available.

2. In Device Manager, right-click the exact Wi-Fi adapter and select Uninstall device.

3. On the first pass, do not select Attempt to remove the driver for this device or Delete the driver software for this device. Retaining the package gives Windows a reversible re-enumeration path.

4. Select Uninstall, then restart Windows normally.

5. After sign-in, wait for Windows to enumerate the adapter. Open Device Manager and confirm the adapter name, provider, version, and status.

6. If Windows restores a generic/old package or the adapter remains absent, run the saved exact-model OEM installer. Restart again when the installer requires it.

7. Reconnect to the intended SSID. Before any other corrective command, save a new ipconfig /all, test the recorded gateway, run nslookup, and test Internet reachability. If connectivity has returned, stop here and attribute the result to driver rollback/re-enumeration; do not add DNS or DHCP changes.

8. Do not flush the client cache merely because nslookup fails. nslookup queries the configured DNS server directly and does not prove that the Windows DNS Client cache is stale. If nslookup itself fails, diagnose the configured DNS server/path instead.

   Refresh the DNS resolver cache only when a direct nslookup returns the current expected answer but resolver-dependent applications or commands still resolve the name incorrectly or retain a negative result. Confirm that split first. For example, compare nslookup www.microsoft.com with the Windows resolver result from PowerShell and inspect ipconfig /displaydns:

   [System.Net.Dns]::GetHostAddresses('www.microsoft.com') |
     Select-Object -ExpandProperty IPAddressToString
   

   A TCP connection failure by itself is not a stale-cache signal; compare the resolved addresses or a retained negative result. Only after that evidence, run:

   ipconfig /flushdns
   

   Successfully flushed the DNS Resolver Cache. is the expected message. This does not renew an IP address or repair the driver by itself.

   Immediately repeat the same resolver-dependent command/application test and Internet reachability test. nslookup may be repeated as the direct-server control, but an unchanged nslookup result is not evidence that cache flushing worked. Record whether this one change was decisive.

9. Separately, and only if ipconfig /all proves that a DHCP-configured adapter retained an invalid lease, release and renew only the recorded adapter:

   ipconfig /release "<adapter-name>"
   ipconfig /renew "<adapter-name>"
   

   Stop if the adapter name is uncertain or a static address is intentional.

10. Repeat ipconfig /all, gateway ping, nslookup, and Internet reachability after that one action and save the after-state. Do not combine DNS flush and lease renewal before measuring each result.

Branch C — Re-enumeration does not fix the failure

1. Do not repeatedly remove the driver package.

2. Compare the after-state to the evidence folder: driver version, Device Manager status, IP address, gateway, and DNS.

3. If Wi-Fi works on another network but not the original one, investigate access-point band/security compatibility, MAC filtering/randomization, DHCP reservations, and router firmware.

4. If Wi-Fi and Ethernet fail identically, return VPN, proxy, security filter, DNS, and Windows networking components to scope.

5. Use a broad Network reset only under a separate procedure that inventories and can restore virtual adapters, VPN clients, Hyper-V/WSL networking, static routes, and custom addresses. It is intentionally not part of this driver-first article.

• Rollback restores Internet access: retain the working driver and monitor the OEM/Windows update path before accepting another driver version.
• Uninstall/restart restores the same or newer driver and connectivity: the adapter/device binding or driver state was likely damaged.
• Gateway works but DNS does not: fix DNS configuration or the configured DNS service; do not keep reinstalling the adapter.
• The PC works on a hotspot but not the home access point: the remaining issue is network-specific; check security mode, radio band, filtering, and DHCP behavior.
• No devices on the access point have Internet: diagnose the router/ISP.
• The adapter disappears or retains Code 10/31/43 after a verified OEM driver: hardware, firmware, or deeper driver-stack diagnosis is required.
• Code 56 remains and VPN/filter software is installed: use the product's supported repair/removal path rather than deleting network-class registry entries.

• Do not uninstall the only network driver before saving the replacement package locally.
• Do not perform this remotely without a tested alternate management path.
• Do not use a third-party driver-download website or automatic driver updater.
• Do not delete every network adapter, including VPN, Hyper-V, WSL, Bluetooth, or virtual adapters.
• Do not run netcfg -d, a Winsock reset, or a full Network reset as an unrecorded first step.
• Do not set every Windows networking service to Automatic; Windows uses service triggers and version-specific defaults.
• Do not remove an organization-managed proxy, certificate, 802.1X profile, VPN, or endpoint filter.
• Do not treat Destination host unreachable as a DNS error without recording its sender.
• Do not repeatedly disable and enable the adapter while an installer is running.

1. If Branch A made connectivity worse, open Device Manager and inspect Roll Back Driver. If it now offers the later version and that version was the recorded starting state, roll forward only when necessary to restore the baseline.

2. Prefer reinstalling the exact original package saved or obtained from the computer manufacturer. Run its installer, restart, and verify the provider/version/date against the initial record.

3. If Branch B retained the driver package, Device Manager can normally re-enumerate it after Action > Scan for hardware changes or restart.

4. If the device was removed with the delete-driver checkbox outside this article, reinstall the saved OEM package. Do not depend on Windows Update while offline.

5. Reconnect the original Wi-Fi profile. Restore any intentionally configured static IP, gateway, DNS, proxy, or VPN setting only from the recorded before-state.

6. If local networking cannot be restored, stop making changes and use the alternate connection or manufacturer recovery package. Do not reset the whole Windows installation for a single adapter without further evidence.

1. Confirm Device Manager shows the intended Wi-Fi adapter without an active error code.

2. Save the after-state:

   ipconfig /all > "%USERPROFILE%\Desktop\WiFi-before\ipconfig-all-after.txt"
   netsh wlan show interfaces > "%USERPROFILE%\Desktop\WiFi-before\wlan-interfaces-after.txt"
   route print -4 > "%USERPROFILE%\Desktop\WiFi-before\route-print-4-after.txt"
   

3. Confirm the adapter has the expected address type, a usable default gateway, and the intended DNS servers.

4. Ping the recorded gateway, run nslookup www.microsoft.com, and load at least two HTTPS sites that were not already open in a browser cache.

5. Restart Windows and reconnect to the same SSID. Repeat the gateway, DNS, and HTTPS tests.

6. Sleep and resume once if the original issue appeared after resume. Do not add this test when sleep was unrelated.

7. Record the working driver provider/version/date and whether rollback or reinstall was the decisive action.

Confidence is approximately 80% that the Wi-Fi driver path is the operative cause when another device proves the access point/ISP works, the failure is isolated to the Windows computer, the driver changed near the onset (or a relevant historical Device Manager problem was recorded and has now cleared), and rollback/reinstall restores gateway, DNS, and Internet access across a restart. A current Code 10/31/43/56 remains routed out of this connected-state article. Two independent source cases reported successful connectivity after driver reinstall; one also flushed DNS. TechXplored has not independently reproduced those cases.

Confidence is lower when the router, VPN, proxy, DNS service, and DHCP state were not separated, or when the only evidence is the Windows network icon.

Stop for a remote-only system without alternate access, a managed enterprise network, missing OEM recovery driver, unstable hardware enumeration, repeated Code 10/31/43 after the correct driver, or failure of every device on the same access point. Stop and route the case to DNS, VPN/filter, router/DHCP, hardware, or network-stack diagnosis when the comparative tests point away from the adapter driver.