How to Reset a Network Adapter Without Locking Yourself Out

Updated: October 2026

Most tickets that end in "reset the network adapter" could have ended two steps earlier, and several of the commands people reach for will disconnect you from the machine you are fixing. This guide covers the order to work in, what each command touches, and the two places Microsoft's own documentation contradicts itself. It also covers the one command that leaves the adapter perfectly healthy while locking you out of the machine entirely.

TL;DR

• Restart one adapter first. Restart-NetAdapter -Name "Ethernet" is the smallest hammer.
• Network reset is the last step, reboots the machine, and returns adapters to defaults.
• Never run these blind over RDP. ipconfig /release and Disable-NetAdapter cut your own session.
• netsh advfirewall reset deletes every custom rule and does not touch the adapter at all.

Start Here, Not With a Reset

Three commands separate the three failure modes before you change anything.

Get-NetAdapter tells you whether the adapter exists and whether it reached Up. Add -Physical to filter out VPN and virtual clutter, -IncludeHidden to find the leftovers from a bad uninstall, and pipe it to Format-Table -View driver for the driver date and version. Microsoft documents that view by name, and it answers "is this a driver problem" in about ten seconds.

If the adapter is Up, ipconfig /all separates DHCP from DNS. An APIPA address or no lease is a DHCP conversation. A valid address with a gateway that pings is not.

Test-NetConnection takes it from there. It returns DNS lookup results, route selection and connection confirmation in one call, which is exactly the split you need. -CommonTCPPort accepts HTTP, RDP, SMB and WINRM; anything else goes in -Port.

One more worth knowing before you flush anything: Microsoft documents the client resolution order as cache, then the Hosts file, then the DNS server. A Hosts entry short-circuits the lookup entirely and never reaches a packet capture, so ipconfig /displaydns before ipconfig /flushdns is how you prove which one you are dealing with.

Skipping that step is how a ticket ends up like this one. An admin runs the entire ladder on two Dell laptops that lose USB and every network interface at once: winsock reset, IP reset, flushdns, the Settings-level network reset, a driver uninstall and reinstall, Fast Startup off, sfc and DISM. None of it moves. The replies point at a chipset fault and a 60-second power drain, neither of which any reset command can reach.

Restarting One Adapter

Restart-NetAdapter -Name "Ethernet" disables and re-enables a single adapter. Microsoft describes it as the way to make certain properties take effect or to put the adapter into a known state, and the name parameter is mandatory, so there is no way to fat-finger it into restarting everything. Wildcards work.

Microsoft's position on tooling is explicit, in an Important callout on the netsh reference: use PowerShell to manage networking in Windows rather than netsh. The netsh commands still work and are still documented, but the cmdlets are the supported route.

Reset-NetAdapterAdvancedProperty is the next size up, resetting driver-level properties to factory defaults. -DisplayName is mandatory, and "*" resets everything on that adapter. Note that it restarts the adapter by default unless you pass -NoRestart, which matters more than it sounds like when you are not sitting at the machine.

The netsh Commands, and What Each One Touches

These get pasted from forum posts more than any other commands in Windows, usually as a block, usually without anyone checking what the individual lines do.

The winsock one deserves a note, because it is the most cargo-culted command on the list. Layered Service Providers have been deprecated since Windows 8, so on a current Windows 11 machine the catalog is usually already clean and the reset is close to a no-op. Run netsh winsock show catalog first and you will usually find nothing worth removing. Where a reboot is genuinely needed, the sourced reason is not the netsh page but Microsoft's LSP documentation, which states that a reboot is required whenever an LSP is installed or removed.

Two contradictions in Microsoft's own documentation are worth knowing rather than guessing at. The first is the restart: Microsoft's consumer troubleshooting article has users run netsh int ip reset and immediately check whether the problem is fixed, while the netsh reference states you must restart for the defaults to take effect. Trust the reference. The second is the log file: a Microsoft page dated February 2026 says you must specify a log file name for the command to run, while the current reference and the consumer article both omit it. Both forms are accepted, and netsh int ip reset c:\resetlog.txt has the advantage of writing down what changed, which is useful on a ticket.

If you want to see the catalog either side of the reset, this walkthrough opens the two registry keys the command swaps between, Protocol_Catalog9 and Protocol_Catalog_Before_Reset.

What Network Reset Does, and What It Does Not

On Windows 11 it lives under Settings, Network and internet, Advanced network settings, Network reset. On Windows 10 it is Settings, Network and internet, Status, Network reset. Microsoft's own framing is that it should be the last step you try.

What Microsoft commits to is narrow: it removes any network adapters you have installed along with their settings, and after the restart the adapters are reinstalled with settings back at defaults. Two notes come with it. You might need to reinstall and set up other networking software such as VPN clients or Hyper-V virtual switches. And it might set each known network connection to a public network profile, which is a quiet way of saying file sharing and discovery will stop working until someone changes it back.

What Microsoft does not say is the more useful half, because the internet fills the gap with confident claims. There is no statement that it deletes saved Wi-Fi profiles, and the wording about known network connections implies those entries survive. There is no mention of proxy settings anywhere. Static IP configuration is only inferable from "set to the defaults" rather than stated. And no Microsoft page gives a countdown before the reboot, so if you have seen five minutes quoted, that is an on-screen string rather than documentation.

Treat the unstated items as unknown rather than safe. Export what you care about first: netsh wlan export profile name="CorpWiFi" folder="C:\WiFiProfiles" key=clear for wireless, and netsh lan export profile folder=C:\lanprofiles for wired 802.1X.

The VPN caveat is the one that costs the most time on a managed fleet. In this thread five machines stop using tunnel-side DNS after a reboot, and the answer sits in the interface metric and the default-gateway checkbox on the virtual adapter. Those are per-adapter properties, which is exactly the category a blanket reset removes rather than repairs.

The Remote Session Trap

Microsoft publishes exactly one direct warning here, on the Disable-NetAdapter page, and it is worth quoting to anyone who runs commands through a remote tool: do not disable the network adapter being used to manage a remote computer. There is no Microsoft article covering what happens when these commands run over RDP or through an RMM agent, so the rest of this section is reasoning from documented behaviour rather than Microsoft guidance.

The ones that cut your session immediately are Disable-NetAdapter on the in-use adapter, which does not come back on its own, and ipconfig /release, which Microsoft documents as disabling TCP/IP on adapters configured for DHCP. Released over RDP, there is nothing left to run /renew from. Restart-NetAdapter and Reset-NetAdapterAdvancedProperty without -NoRestart both bounce the link, which a remote tool will usually survive unless the adapter comes back on a different address.

The deferred one is the netsh IP reset family. The command returns fine and the session holds, because the change lands on reboot. The risk arrives with the restart, when a static address is gone and the machine may not be where you left it.

Then there is netsh advfirewall reset, which is the genuinely dangerous one and is not in Microsoft's consumer troubleshooting list at all. It does not touch the adapter, so nothing looks wrong. It deletes every custom firewall rule and every connection security rule, and in a Group Policy object it returns all settings to not configured. If remote access depends on a custom inbound rule for an RMM agent listener or a non-default RDP port, the NIC stays perfectly healthy while you lose the machine. Always run it as netsh advfirewall reset export C:\fw-backup.wfw.

The supported pattern for all of this is to run the command from somewhere it cannot cut off. Every NetAdapter cmdlet takes -CimSession, documented as running the cmdlet against a remote computer, so the shell lives on a machine that stays up. The netsh equivalent, netsh -r, is mostly theoretical in the field, because Microsoft notes it needs the Remote Registry service running and that service is disabled by default on modern Windows.

Uninstalling the Driver

Microsoft places this at step 8 of its own sequence, ahead of network reset at step 13, and flags the trigger condition worth remembering: consider it if the connection stopped working properly after a recent update.

In Device Manager, under Network adapters, right-click the adapter and choose Uninstall device, then tick Attempt to remove the driver for this device. That is the current string; older guides still say "delete the driver software". Restart, and Windows reinstalls a driver on its own.

The checkbox is the whole decision. Leave it unticked and the driver package stays in the driver store, so the reboot reinstalls the same driver and you have reset the device instance rather than the driver. Tick it and Windows falls back to an inbox driver or to nothing at all, which is the right call when the driver itself is the suspect and the wrong call if you have not staged the vendor driver somewhere first. Microsoft's own instruction is to download the vendor driver to a USB stick before you start, because the machine may come back with no network to download it with.

If the crash side of this is what brought you here, our guide to the blue screen of death covers reading the dump, and Microsoft's published split puts 70% of crashes on third-party driver code.

Domain-Joined Machines

Microsoft has not published anything on how network reset interacts with domain connectivity, 802.1X wired profiles, certificate-based Wi-Fi or Group Policy applied settings. That silence is itself worth planning around on a managed fleet.

What is documented gives you the shape of it. Wired and wireless 802.1X profiles are per-interface objects managed through netsh lan and netsh wlan, and network reset removes and reinstalls adapters, so there is a clear mechanism by which those profiles would be lost even though Microsoft does not say so. Group Policy delivered network settings are re-applied at the next policy refresh, which sounds reassuring until you notice the catch: the machine has to reach a domain controller to get them, and reaching a domain controller is the thing a broken 802.1X port prevents.

Machine certificates live in the certificate store rather than in adapter configuration, so a reset does not remove them, but it can remove the profile that points at them. Microsoft's 802.1X troubleshooting guidance is worth reading first in any case, because it states that most 802.1X authentication issues come down to certificate problems: invalid, expired, chain verification failure or revocation check failure.

For wireless and wired authentication failures specifically, the logs are under Applications and Services Logs, Microsoft, Windows, in WLAN-AutoConfig/Operational and Wired-AutoConfig/Operational. The certificate log at CAPI2/Operational is disabled by default and has to be enabled before it records anything.

What to Do Next

Work upward in blast radius. Restart the one adapter, then check DHCP and DNS separately, then reach for netsh, and treat network reset as the last step Microsoft says it is.

Before anything destructive, export what is not documented as safe: the wireless profiles, the wired 802.1X profiles, and the firewall rules. Those three exports take under a minute and cover every item Microsoft declines to make a promise about.

And decide where you are running the command from before you run it. If you are inside the session that depends on the adapter you are about to reset, use -CimSession from another machine instead. Our network management software guide covers the tooling that gives you that second vantage point.

Endpoint management platforms are the other half of it, letting you push a fix to a machine without depending on the link you just broke.