Fix RPC_NT_ADDRESS_ERROR 0xC0020045 on Windows Server

The error string looks scary, but RPC_NT_ADDRESS_ERROR isn't as mysterious as it sounds. What's actually happening is that the RPC runtime tried to hand a network address (port, endpoint, or IP) to an RPC server process, and the server rejected it because the address was malformed, already claimed, or bound to an interface that no longer exists. You'll see it most often on domain controllers after a NIC change, on clustered SQL nodes during failover, and on Windows Server 2016/2019 boxes where someone just swapped a vSwitch on the hypervisor side.

The error typically shows up in one of four places: an application event log entry, a failed backup job (Veeam, Windows Server Backup), a DFSR replication stall, or a dcdiag /test:rpc output. If you're getting it from a third-party app that talks to a remote server over RPC, the fault is almost always on the listening side, not the client. Start there.

Step 1 (30 seconds): Restart the RPC service and check the binding

Nine times out of ten, this is a stale endpoint registration. The RPC endpoint mapper (rpcss) caches dynamic port assignments, and if a service crashed without deregistering, the next bind attempt hits a collision.

net stop rpcss /y
net start rpcss

You can't stop rpcss from the Services console without also taking down DCOM, so use the command line as shown. On a domain controller you'll get a warning that dependent services will stop — that's expected, let it happen.

While you're in there, verify the endpoint mapper is actually listening on TCP 135:

netstat -ano | findstr :135
sc query rpcss

You want to see a LISTENING line with a PID that matches the rpcss process. If 135 is missing, someone's hardened the box with a policy that broke RPC, or a third-party firewall (Symantec Endpoint, old McAfee HIPS) is intercepting the bind.

Stop here if the application now connects. If not, move on.

Step 2 (5 minutes): The interface address is wrong

Here's where most admins burn an hour. They assume it's a firewall and open ports 135 + the dynamic range 49152-65535 — and the error doesn't change. That's because 0xC0020045 isn't a connectivity error. It's a binding error. The RPC server is trying to bind to an IP that isn't on the machine anymore.

Classic trigger: you P2V'd a physical server, or you changed a NIC team on Hyper-V, and Windows still has a phantom IP registered. The service that's failing has that old IP hardcoded in its configuration.

Check what addresses the box thinks it has:

ipconfig /all
netsh interface ipv4 show addresses
route print -4

Now check the registry for stale bindings. The most common culprit is a leftover entry under:

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces

Each subkey is a GUID that corresponds to an adapter. If you find a GUID with a static IP that doesn't match any current adapter, that's your ghost. Don't delete the key outright — export it first, then remove it. Reboot.

If this is a clustered resource (SQL AG, File Server role), also run:

cluster res "SQL Network Name (YourAG)" /priv
cluster res "SQL IP Address 1 (YourAG)" /priv

and confirm the IP resource is online and matches the current subnet. A cluster IP resource stuck in Failed state will throw 0xC0020045 from any RPC-dependent operation.

Step 3 (15+ minutes): Reset the RPC stack and winsock

If the first two didn't fix it, the RPC runtime itself is corrupted. This happens after a botched Windows Update, an antivirus driver that hooked LSP (Layered Service Provider), or a system restore that rolled back some RPC DLLs but not others.

Before you reset, back up the RPC state:

reg export HKLM\SOFTWARE\Microsoft\Rpc backup_rpc.reg
reg export HKLM\SYSTEM\CurrentControlSet\Services\Rpc backup_rpc_svc.reg

Now reset winsock and the TCP/IP stack:

netsh winsock reset
netsh int ip reset
netsh int ipv6 reset

The reason this works is that LSPs and filter drivers register themselves in the winsock catalog, and RPC uses winsock underneath. A bad LSP will let TCP/IP work fine for normal traffic but break the specific bind() call RPC makes with a local address. You'll need to reboot after these commands — don't skip that.

After reboot, re-register the RPC services:

regsvr32 /s rpcrt4.dll
regsvr32 /s rpcss.dll
net stop rpcss /y
net start rpcss

Then rebuild the endpoint mapper database by restarting the services that depend on RPC. If this is a domain controller, give it 10 minutes before you run dcdiag /test:rpc again — the KDC and Netlogon take a moment to re-register their endpoints.

Verify the fix

Run this from a different machine on the same subnet, not from the server itself. Testing locally hides binding problems.

rpcdump /p 135
portqueryui

Or if you don't have the Windows SDK tools handy, just hit it with PowerShell:

Test-NetConnection -ComputerName  -Port 135

Then re-run whatever was throwing the error. If it's dcdiag, look for the RPC Bind Test result. If it's a backup job, kick it off manually.

What NOT to do

• Don't disable the Windows firewall and call it fixed. If disabling the firewall makes the error go away, you have a port-range rule problem, not an RPC problem. The dynamic port range for RPC is 49152-65535 on Server 2008 R2 and later — that's a lot of ports to open, and a proper fix is to restrict RPC to a static range with netsh int ipv4 set dynamicport tcp start=50000 num=100.
• Don't set rpcss to Disabled to stop the errors from showing in the event log. You'll break DCOM, WMI, Group Policy processing, and probably your ability to log in interactively. I've seen this done. It was not a good day.
• Don't trust the "port already in use" explanation unless you've actually confirmed it with netstat -ano. RPC uses ephemeral ports and collisions are rare in practice — the ghost-interface scenario above is far more common.

When it's actually DNS (yes, really)

One more scenario worth a mention because it wastes people's time. On domain-joined servers, 0xC0020045 sometimes appears alongside Event ID 5719 ("No domain controller is available") and DCOM 10009. The RPC call is failing because the target name resolved to an IP that isn't the machine's real address — a stale A record, a multi-homed server with a bad NIC order, or a DNS suffix search list that's returning the wrong host.

Run nslookup from the client. If it returns anything other than the server's primary IP, fix DNS first. Everything else in this article is downstream of that.