ERROR_INCORRECT_ADDRESS (0X000004D9): Why Windows Rejects Your Network Address

If you're staring at ERROR_INCORRECT_ADDRESS (0x000004D9) — "The network address could not be used for the operation requested" — you've probably just changed a NIC config, edited a bindings file, or tried to set up port forwarding. This is a Winsock-family error. The number 0x4D9 is 1241 in decimal, and it maps to what POSIX folks call EADDRNOTAVAIL. Translation: the address you asked the OS to bind to isn't available on the machine, or the format itself is junk.

I've hit this on Server 2012 R2 boxes after a VLAN change, on IIS after a server move, and on somebody's dev laptop after they hardcoded a public IP into a config. It's almost never "Windows is broken." It's almost always a mismatch between what you told an app to use and what the machine actually has.

Cause #1: You're binding to an IP that isn't on this machine

This is the big one. Nine times out of ten, the app config or a command line points to an IP that simply doesn't exist on any adapter right now. Could be a stale DHCP lease, could be a public IP you assumed was NAT'd to you but isn't, could be a typo in an octet.

Check what the box actually has:

ipconfig /all
netsh interface ip show config
Get-NetIPAddress -AddressFamily IPv4 | Select IPAddress, InterfaceAlias

Every address you bind to must appear in that list. No exceptions. If your app is trying to listen on 192.168.10.50 and the NIC is sitting on 192.168.1.50, you get 0x4D9. Fix the config — don't add the phantom IP as a secondary unless you actually need it.

Classic trigger: someone moves a VM between hosts, the new VLAN hands out a different subnet, but the Apache/IIS/sql config still has the old address hardcoded. Same story if you assigned a static IP and forgot, then re-enabled DHCP.

If you absolutely need a second IP

You can add it, but know what you're doing:

netsh interface ipv4 add address "Ethernet" 192.168.10.50 255.255.255.0

Then re-check binding. If the app now starts, great — but you've got two IPs on one NIC, and you'd better know which one inbound traffic will land on.

Cause #2: Wrong wildcard or address family — 0.0.0.0 vs. specific IP vs. ::1

Second most common. You're on the right subnet, address exists, but the form of the bind is wrong for the socket family. Asking an IPv4 socket to bind ::1 or vice versa throws 0x4D9 just as happily as a missing IP.

Things that trip people up:

• Binding to 127.0.0.1 when you meant 0.0.0.0. Loopback-only means nobody off-box can reach it — sometimes you get a bind error from services that insist on a routable address.
• An app that binds IPv6 by default. Windows prefers IPv6 for name resolution since Vista, so localhost may resolve to ::1 first. Your config says IPv4, the socket wants IPv6, boom.
• HTTP.sys URL reservations with a hostname that doesn't resolve. netsh http add urlacl url=http://myserver:8080/ user=Everyone fails if myserver isn't resolvable on that NIC.

Quick check on what's actually listening and on which family:

netstat -ano | findstr :443
tasklist /svc | findstr <PID>

If you see [::]:443 you're on IPv6. If you see 0.0.0.0:443 you're on IPv4 wildcard. Force the app to match your intent. In IIS, that's the site bindings dialog — set it to "All Unassigned" or pick the exact IP, not a hostname that resolves to the wrong stack.

Cause #3: Port/address already reserved or blocked by another service

Third place. The address exists, the format is right, but the combination is already claimed. ERROR_INCORRECT_ADDRESS sometimes shows up here instead of the cleaner WSAEADDRINUSE (10048), especially on Windows because HTTP.sys and the kernel proxy layer do their own arbitration.

Usual suspects:

1. Another service grabbed the port. Skype used to be notorious for 80 and 443. So does BranchCache, Web Deployment Agent, and sometimes SMB on 445.
2. An HTTP.sys URL reservation is stomping on yours. Run:

netsh http show urlacl
netsh http show servicestate

If you see a reservation on the URL you want, either delete the conflicting one or add your own with a more specific path:

netsh http delete urlacl url=http://+:8080/
netsh http add urlacl url=http://+:8080/ user="NT AUTHORITY\LocalService"

Also check the firewall isn't silently dropping the bind attempt through a third-party filter driver. Symantec Endpoint, older McAfee HIPS, and some VPN clients (looking at you, legacy Cisco AnyConnect) install Winsock LSPs that intercept binds and occasionally cough up 0x4D9 instead of a clean error. Test by temporarily disabling the filter or running the app on a clean VM.

Rule of thumb: if a service works on Machine A and throws 0x4D9 on Machine B with identical config, you have an LSP or firewall filter difference. Don't waste hours on the app.

One more thing about port forwarding

If you're setting up NAT on a router and the internal IP you're pointing at doesn't match the machine's real address, some Windows-based NAT tools (RRAS, third-party proxies) report 0x4D9 instead of "host unreachable." Double-check the target IP. I've seen this on Server 2016 RRAS more than once — the port forward was fine, the destination IP had a typo.

Quick reference: match the symptom to the fix

Start with cause #1 every time. Run ipconfig /all, compare it to your config, and I'd bet money that's the whole story. The rest of these are edge cases you only reach after the obvious check has been ruled out.