Fix ERROR_ADDRESS_ALREADY_ASSOCIATED (0x4CB)

You're setting a static IP on a second NIC, or you just spun up a Hyper-V vSwitch, or you restored a VM from backup. You hit Apply and Windows throws ERROR_ADDRESS_ALREADY_ASSOCIATED (0x000004CB). Nothing else. Just that hex code and a dead network adapter. I've seen this on Server 2016 through Server 2022, and on Windows 10/11 workstations after someone clones a machine without sysprep.

The trigger is almost always the same: you're trying to assign an IP address that's already claimed by another interface on the same box. Windows won't let two adapters own the same IPv4 address, even if one of them is disabled. The error comes from the Winsock layer during a bind() call — codes 0x4CB and WSAEADDRINUSE (10048) are cousins and show up in the same family of problems.

What's actually happening

Every IP address on Windows is associated with a single interface. The TCP/IP stack keeps an internal table. When you try to bind an address that's already in that table — even to a different adapter — the kernel returns STATUS_ADDRESS_ALREADY_ASSOCIATED. That gets mapped to error 0x4CB at the API level.

Three things cause it most of the time:

A leftover static IP on a disabled or hidden adapter (often a VPN TAP driver or a Hyper-V virtual adapter).
A duplicate in the registry under HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces.
An application already bound to that address and port, so the stack refuses to associate it with a new interface.

You can't just click through this. Windows doesn't offer a workaround in the GUI. You have to find the ghost and remove it.

Fix it step by step

Open an elevated command prompt. Right-click Command Prompt, Run as administrator. You'll see Administrator: in the title bar — if you don't, close it and try again.
List every interface and its IP assignments. Run:
```
netsh interface ipv4 show config
```
Scroll through the output. You're looking for the IP you're trying to assign — it'll show up under a different interface name. Common offenders: Ethernet 2, vEthernet (Default Switch), Local Area Connection* 12, or a leftover TAP adapter from OpenVPN.
Check hidden adapters too. Disabled NICs still hold their IPs in the registry:
```
netsh interface show interface
```
If you see a disconnected or disabled adapter, that's likely your ghost. Note the exact name.
Release the address from the ghost adapter. If it's a DHCP-assigned interface:
```
ipconfig /release "Ethernet 2"
```
If it's static, clear it:
```
netsh interface ipv4 set address name="Ethernet 2" source=dhcp
```
Replace Ethernet 2 with whatever the ghost is called on your box. After running this, you'll get Ok. — nothing fancy, but it means the address is released.
Try assigning your IP again. Back in the adapter properties, set your static IP. If it saves without the error, you're done. If it throws 0x4CB again, the association is stuck below the netsh level — keep going.
Hunt the registry. Open regedit.exe and navigate to:
```
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces
```
Each subkey is a GUID that maps to an adapter. Open each one and check the IPAddress value. When you find the GUID holding your target IP, look at its DhcpIPAddress or IPAddress value — that's the ghost. Note the GUID.
Match the GUID to the adapter. Back in an admin prompt:
```
getmac /v /fo list
```
Look at the Connection Name and Network Adapter fields. Then in Device Manager, enable Show hidden devices under the View menu. You'll see the phantom adapter now. Disable or uninstall it.
Reboot. Not optional here. The TCP/IP stack caches associations and won't flush them until restart. A reboot takes 30 seconds and saves you an hour of head-scratching.
Reassign your IP. It'll stick this time.

Skip the temptation to just netsh winsock reset. It won't touch an IP association — that's a Winsock catalog problem, not this one. I've watched techs burn an hour on that command chasing 0x4CB. It does nothing here.

If it still fails after a reboot

Something is actively binding that address, not just holding it. Check the obvious first:

Stop any running VM in Hyper-V or VMware Workstation. A guest with a bridged adapter can hold the host's IP.
Check Docker Desktop. Its default network can grab 172.x addresses and conflict with a custom static.
Run netstat -ano | findstr :445 (or whatever port matters to your app). The PID at the end — feed it to tasklist /fi "pid eq XXXX" to see who owns it.
Disconnect any USB Ethernet adapters. They show up as new interfaces and can inherit stale config.

One more thing worth checking: if this is a domain-joined server, confirm DHCP isn't handing out the same address via a reservation. Group Policy can also push IP config from a stale GPO — run gpresult /h gpreport.html and search for IPAddress in the output.

Once you've removed the ghost adapter and rebooted, the error stops showing up. If you're still seeing 0x4CB after all of that, the problem isn't the OS — it's an application. Look at what starts at boot and binds to your target port or address.