Ethernet Doesn't Have a Valid IP Configuration: 11 Fixes That Work in 2026

When Windows tells you that ethernet doesn't have a valid IP configuration, it is reporting one specific thing. The adapter asked for an address, nothing usable came back, and Windows gave it a placeholder instead. The placeholder is almost always something starting 169.254, and that address cannot leave your own network segment.

That matters because it tells you where to look. This is a handshake failure between one machine and whatever hands out addresses on your network — not a mysterious Windows fault, and not something a repeated troubleshooter run will talk its way out of.

So this guide is ordered the way an admin would work it. Read the adapter's own output first, run eleven fixes in the order that makes sense, and stop at the one that changes the output. Every command below, and every claim about what Windows is actually doing, is checked against Microsoft's own documentation and quoted, on 30 September 2026. Where Microsoft documents nothing, I say so rather than filling the gap.

Author: Robert Harrison OSINT & Network Utility Expert

My honest position on this error is that most guides get the order wrong. They open with a list of commands, which means you run five of them, one works, and you never learn which. I would rather you spend ninety seconds reading ipconfig /all first, because the address Windows put on the adapter already narrows the cause to two or three possibilities before you touch anything.

The honest limit is this: Microsoft's own Ethernet troubleshooting page does not name this message anywhere on it, and I could not find a Microsoft article written about this exact string. So nobody — including me — can tell you which cause is most common, because no vendor publishes that data. What I can do is show you what Microsoft does document about each mechanism, and where the internet's most-copied command is quietly wrong.

What Does Ethernet Doesn't Have a Valid IP Configuration Mean?

It means the adapter has no address it can use on your network. Windows asked a DHCP server for one, got nothing it could use, and fell back to Automatic Private IP Addressing — APIPA, the self-assignment mechanism used when no server answers. The adapter ends up with an address, which is why it looks connected. That address is useless for reaching anything beyond the local wire.

Microsoft's documentation on automatic addressing names the range involved: "The Internet Assigned Numbers Authority (IANA) has reserved 169.254.0.0-169.254.255.255 for Automatic Private IP Addressing", and it notes that APIPA "provides an address that is guaranteed not to conflict with routable addresses." Guaranteed not to conflict with routable addresses is a polite way of saying it is not one.

So what is a valid IP configuration? An address that belongs to your own subnet, a mask that matches it, and a gateway reachable through that mask. Lose any one of the three and the adapter has an invalid IP configuration, which is how some tools and most translated versions of the message word it.

The same page says Windows keeps trying in the background. It states that the machine "will then send out a Discover message every three minutes." A few lines later it says "the computer then broadcasts four discover messages, and after every 5 minutes it repeats the whole procedure until a DHCP server comes on line." Both numbers are Microsoft's and they do not agree, so treat the retry interval as roughly every few minutes rather than a figure worth quoting.

For the mechanism itself, why a 169.254 address never leaves your own network segment goes further than this page needs to. How a server hands out a lease in the first place covers the request that failed.

One reason this error feels rarer than it is: the wording changes with the adapter's name and with the operating system, so people searching the same fault never meet each other. Windows uses one message string and substitutes the adapter name into it. Other systems describe the same state in their own words.

Every row means the machine has no usable address. Which wording you see tells you nothing about the cause — the first three are one Windows string with three different adapter names in it. The adapter's own output does tell you something, so start there.

Read Your Ethernet IP Configuration Before You Change Anything

Open a Command Prompt and run one command. The output tells you which of three states the adapter is in, and each state points at a different set of fixes. This takes less time than one troubleshooter run and it stops you from applying a driver reinstall to a cable problem.

That last row needs a caution, because I cannot tell you exactly when Windows Network Diagnostics chooses to print this particular sentence. Microsoft does not publish the troubleshooter's criteria, and its own Ethernet support page never uses the phrase. What the output means is not in doubt though: an address on your own subnet with a blank gateway is a routing fault, not an addressing one, so the eleven fixes below aim at the wrong layer. That is the neighboring family, covered in where this error sits among the other ways an address fails.

If you do end up assigning an address by hand later in this guide, you will need to know which addresses are legal inside your router's mask. Our subnet calculator returns the network address, the usable host range and the broadcast address for any IPv4 address and prefix. That beats counting in binary on a phone while your desktop is offline. With the state identified, work the commands in order.

How to Fix Ethernet Doesn't Have a Valid IP Configuration: The Command Sequence

Five commands, run as administrator, in the order Microsoft itself uses. Its support page "Fix Ethernet connection problems in Windows" lists them under "Run network commands" and describes their job as to "manually reset the TCP/IP stack, release and renew the IP address, and flush and reset the DNS client resolver cache." That is the whole software layer this error lives in.

One of those commands needs a reboot before it means anything, and it is documented. Microsoft's netsh reference for interface IPv4 says of reset: "Resets the IPv4 configuration state. A reboot is required for changes to take effect." Microsoft's consumer support page does not mention restarting at all — it says to run the commands in order "and then check to see if that fixes your connection problem."

Follow the command reference rather than the shorter advice: run the set, restart, then judge. Re-testing immediately is how people conclude a fix failed before it was applied. I found no Microsoft source requiring a restart for netsh winsock reset, so I am not claiming one — the restart for the IPv4 reset covers both anyway.

If the output changed and you now have an address on your own subnet, you are done. If it did not, one command in that list is usually copied with an extra argument it does not need, and that is worth understanding before you conclude it failed.

Does netsh int ip reset Need a Logfile?

Not on Windows. The question keeps getting asked because Microsoft publishes both forms, in two maintained places, for two different audiences — neither of them out of date.

Microsoft's consumer support page for Ethernet problems, quoted in the previous section, tells Windows users to run netsh int ip reset with no argument at all. That is your evidence that the command works bare on Windows 10 and 11.

Then there is the other one. Microsoft's Windows Server troubleshooting article on resetting TCP/IP gives the command as netsh int ip reset c:\resetlog.txt and states that "to run the manual command successfully, you must specify a name for the log file in which the netsh actions will be recorded." That page is dated 12 February 2026 and applies to supported versions of Windows Server, so it is not an old article someone forgot to take down.

A third source says what the command itself accepts: Microsoft's netsh reference for interface IPv4 documents reset with the syntax "reset" and its parameters as "none". Be fair to that page, though — it is archived and its header reads "Applies To: Windows Server 2008", so it tells you the command's documented form, not what today's Windows requires.

One more note on scope. The Server article states that the reset "has the same effect as removing and reinstalling TCP/IP" and names the two registry keys it overwrites, so anything you configured by hand — a static address, custom DNS servers, a fixed metric — goes back to defaults. Write down what you had first. Which brings us to the variant almost nobody writes about.

Why Does It Say Ethernet 2 Doesn't Have a Valid IP Configuration?

Because an earlier instance of the adapter already took the plain name, so Windows numbered the new one. That is the whole answer, and it is worth saying plainly: the number is a naming artifact, not the reason you have no address. Ethernet 2, Ethernet 3 and Ethernet 4 are normal names on a machine whose network card has been reinstalled, moved or replaced.

Microsoft does not publish a page stating the numbering rule, which is why the results for this exact phrasing are almost entirely forum posts. An archived Microsoft support blog does explain the mechanism — it labels itself archived, so treat it as background. It says "the network adapter will be assigned a name based on the device driver INF file," that the Network Setup Service "will try to keep the original network adapter name during the driver update progress," and that "this issue will not happen if the previous version network adapter driver is 'uninstalled' before install the new version driver."

Read that last clause next to fix 9. Uninstalling the adapter before installing a new driver both avoids the duplicate name and actually rebinds the driver. Updating in place does neither.

Where the hidden adapter genuinely matters

Not here, and I will be blunt because the forum threads on this error send people ghost-hunting. The old instance is a non-present device: hardware Windows remembers but cannot see. It has no active binding, so it is not intercepting your DHCP request. Microsoft's own documentation on viewing hidden devices is unusually direct about it: "a non-present device should not have their attention and should not cause any problems."

Where it does bite is fix 10, when you set an address by hand. Microsoft's article on setting an IP address gives Windows' own dialog text for that case: the other adapter "is hidden from the network and Dial-up Connections folder because it is not physically in the computer or is a legacy adapter that is not working."

The cause it gives is "a network adapter with the same IP address is in the registry but is hidden in Device Manager," which "can occur when you move a network adapter from one PCI slot to another PCI slot." Its resolution is one line: "uninstall the ghosted network adapter from the registry."

How to look, on Windows 10 and 11

Here is another line the internet copies without checking: almost every guide tells you to set an environment variable first. Microsoft's own documentation scopes that step to old Windows — "prior to Windows 8, to view non-present devices, you must set the environment variable DEVMGR_SHOW_NONPRESENT_DEVICES to 1 before you open Device Manager."

On Windows 8 and later that page gives one step: "to include hidden devices in Device Manager display, select View and select Show hidden devices." That is all you need. The variable does no harm, but it is not what makes the ghosts appear.

A hidden Intel or Realtek entry alongside a working one of the same family is usually a leftover from a slot change, a motherboard swap or a driver reinstall. A hidden entry from a vendor you do not recognize is more interesting: VPN clients, LAN-emulation tools such as Hamachi, VMware and Hyper-V all register themselves as network adapters, and any of them can leave one behind.

If you cannot tell what a leftover entry was, its MAC address will. The first six hex digits are the vendor prefix. You can look up which manufacturer a hidden adapter's prefix is registered to before you remove anything: the tool reads the IEEE registry, returns the vendor, and lists the VMware prefixes explicitly. Identify first, uninstall second.

So the numbered name is explained and the ghost is probably innocent — worth knowing, because it saves you an evening. It is a close relative of the conflict message Windows raises when an address is already claimed, which is a real fault rather than a leftover. If none of your adapters are duplicated, the next clue is which of your two connections works.

Ethernet Doesn't Have a Valid IP Configuration but WiFi Works: What That Rules Out

It rules out most of the network. If the same machine gets a working address over Wi-Fi from the same router, then the router's DHCP service is running, it has addresses left to give, and the link behind it is up. None of those can be your problem. That removes half of every fix list on the subject, including restarting the router — the advice you will be given first almost everywhere.

What is left is everything specific to the wired path: the cable, the wall port, the switch between you and the router, the Ethernet controller, its driver, and any ghost instance on that one interface. Work it in that order. The cheapest test is also the most common cause.

A partial failure is the awkward case. A cable with a damaged pair can pass enough signal for Windows to show a link light and call the adapter connected, while dropping the broadcast frames a DHCP request depends on. That is why "the light is on" is not evidence, and why swapping the cable is fix 11 rather than a last resort. If the wired path checks out and you still have no address, assign one yourself.

How to Give Ethernet a Valid IP Configuration by Hand

Setting the address manually is a diagnostic as much as a fix. If a hand-configured address works, DHCP is the broken part and the hardware is fine. If it does not work even with correct values, the fault is below the IP layer and no amount of configuration will reach it. Either answer is worth having.

You need four values, and three of them come from a device on the same network that already works. On a working machine, run ipconfig and note its IPv4 address, its subnet mask and its default gateway.

1. Press Windows and R, type ncpa.cpl, press Enter.
2. Right-click the Ethernet adapter, choose Properties.
3. Select Internet Protocol Version 4 (TCP/IPv4), then Properties.
4. Choose "Use the following IP address".
5. Open the router's LAN settings page and read its DHCP range. Do not skip this step; there is no number that is safe on every router.
6. Enter an address on the same network as the working device but outside that range. If the router hands out 192.168.1.100 to 192.168.1.199, then 192.168.1.50 is free. If it hands out 192.168.1.2 to 192.168.1.254 — which is the documented default on some consumer routers — then no address is free and you must shrink the pool first.
7. Enter the same subnet mask and the same default gateway as the working device.
8. For DNS, enter the gateway address, or a public resolver if you prefer.
9. Click OK, close the dialogs, then run ipconfig /all to confirm the values stuck.

Two things go wrong here. The first is picking an address inside the router's DHCP pool, which sets you up for a conflict the next time the router hands that address out. The common advice — "just pick a high number" — is wrong on any router whose default pool runs to the end of the subnet, and that includes documented defaults on mainstream consumer hardware.

So read the pool rather than guessing at it. The second mistake is getting the mask wrong, which quietly makes the gateway unreachable: the mask decides which addresses Windows treats as local, and 255.255.255.0 is the right answer on almost every home network.

On Windows 11 the same values go in under Settings rather than ncpa.cpl, and PowerShell can set them in one line. Setting a fixed address on every Windows version, including from the command line covers each route. Once you have proved the adapter works with a manual address, the remaining question is the driver.

Should You Reinstall the Driver, and Does Windows Update Fight You?

Reinstall rather than update, and no — Windows Update is far less aggressive about replacing your driver than the advice suggests. Both halves of that matter, because the usual instruction is "update the driver," which is the one action least likely to change anything.

Update driver in Device Manager asks Windows to find something newer. If the current driver is already the newest one Windows knows about, nothing happens, and a corrupted or badly bound driver stays exactly where it is. Uninstalling the device with Delete the driver software for this device checked, then restarting, forces Windows to enumerate the adapter from scratch and rebind it. That is fix 9, and it is a different operation from an update.

On the fear that Windows Update will immediately overwrite a manufacturer driver you just installed: Microsoft's published rules for driver distribution say otherwise, and it is worth reading them before you go disabling update services.

So the practical order is short. Download the driver for your exact model from the motherboard or NIC vendor's site on a machine that works, copy it across, uninstall the adapter with the delete-driver box checked, restart, then install the vendor package. Disabling Windows Update to protect that driver is solving a problem Microsoft's own rules say you do not have.

One caveat you may have read about does not apply to you. Microsoft's driver selection documentation does describe a case where a Microsoft-signed package outranks a third-party-signed one — but only when the AllSignersEqual group policy is disabled, and the same page states that "starting with Windows 7, the AllSignersEqual Group Policy is enabled by default." On any Windows 10 or 11 machine you own, all digitally signed packages rank equally. If you have now done all eleven fixes and the adapter still has no address, the cause is somewhere this guide has not sent you yet.

You Tried Everything and Ethernet Still Has No Valid IP Configuration

Then stop repeating the list. Every fix above addresses one machine's software or one cable's copper. If all eleven have failed, the cause is on the network side or in the hardware, and it needs a different kind of test rather than another reset. Here is what to check next, matched to what you are actually seeing.

Two honest limits. First, no page can tell you which of these it is: no vendor publishes cause-frequency data for this error, and Microsoft's Ethernet troubleshooting page does not name the message at all, so a percentage attached to any single cause has nothing behind it. Second, if a manual address works and the adapter passes on another network, the machine is fine. The answer is on the infrastructure, which is usually a conversation with whoever owns the switch.

One last thing, if the troubleshooter is your only evidence. Windows Network Diagnostics sometimes reports a proxy result for the same connection in the same session, and that message has its own causes and fixes. Which brings us to the summary.

The Short Version

When ethernet doesn't have a valid IP configuration, the adapter asked for an address and got nothing it could use, so Windows self-assigned one in the 169.254 range that cannot route. Read ipconfig /all before you change anything. A 169.254 address, a disconnected media state and a leftover static address are three different problems wearing the same error message.

Then work the eleven fixes in order and stop at the one that changes the output. Restart rather than shut down, release and renew, the two netsh resets with a reboot after them, flush the resolver, cycle the adapter, confirm the DHCP Client service is running, clear out ghosted adapters, reinstall rather than update the driver, set an address by hand as a test, and swap the cable, port or switch. Skip the logfile path on netsh int ip reset — Microsoft's own command reference documents that command with no parameters.

If the troubleshooter also reported that Windows could not detect this network's proxy settings, the proxy message that shows up alongside this one has its own causes worth ruling out.

Once you have an address again, check whether what you ended up with is a lease or a fixed assignment. And if you set an address by hand to get moving, put the adapter back on automatic once DHCP works — a hand-picked address inside the router's pool is tomorrow's conflict.