Fixing RPC_NT_NO_INTERFACES (0XC002004F) Error on Windows Server
This error means no RPC interfaces are registered. Usually it's a firewall or service issue. Here's the quick fix and why it works.
Yeah, I know this error is a pain. You're trying to get something done — maybe a remote management tool, a backup job, or some app — and you get hit with RPC_NT_NO_INTERFACES (0XC002004F). It means no interfaces have been registered. Let me save you some time.
First, the quick fix
Open an elevated Command Prompt or PowerShell. Run these two commands:
net start rpcss
netsh advfirewall firewall set rule group="Remote Administration" new enable=Yes
If RPC service (rpcss) isn't running, that's your issue right there. If it's running and you still get the error, check if the firewall rule for Remote Administration is enabled. The culprit here is almost always that a recent Windows update or a Group Policy change disabled that rule.
If that doesn't fix it, reboot the server. I know it's cliché, but with RPC, a reboot clears stale state in the endpoint mapper.
Why that works
RPC works like a phone directory. When an app wants to call another machine, it asks the RPC Endpoint Mapper (port 135) for the right port. The endpoint mapper can only give you a port if the app has registered an interface with it.
If the RPC service itself is stopped, nothing can register. That's why we start it first. Then, even if the service is running, the remote management firewall rule opens port 135 and the dynamic RPC ports (usually 49152-65535 in modern Windows). Without that rule, the client can't reach the endpoint mapper.
I've seen this happen most often after a Windows Update on Server 2016 or 2019. Microsoft changed firewall settings in some cumulative updates, and if you have a custom GPO, it might conflict.
Less common variations
DCOM permissions messed up
If the firewall and service are fine, check DCOM permissions. Open Component Services (dcomcnfg). Go to Component Services > Computers > My Computer > Properties > COM Security. Make sure the user account that's failing has Access Permission and Launch and Activation Permission set to Allow.
# Check if a specific user has permissions
$sid = (Get-WmiObject Win32_UserAccount -Filter "Name='username'" | Select-Object -ExpandProperty SID).Value
# Then look for that SID in the DCOM permissions (manual in dcomcnfg is easier here)
Registry corruption in RPC mapping
Sometimes the endpoint mapper's registry key gets corrupted. You'll see this if you recently uninstalled an app that used RPC. Run this in regedit:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc\Internet
Look for any weird subkeys. If you see something like {00000000-0000-0000-0000-000000000000}, delete it. Then restart the RPC service. Don't mess with the other keys unless you know what you're doing.
IPv6 disabled incorrectly
Some admins disable IPv6 to "fix" other things. But RPC on Windows Server uses IPv6 for certain interface registrations. If you've disabled IPv6 entirely (not just on a NIC), RPC can't register addresses. Enable it back via registry:
netsh int ipv6 reset
Then reboot.
Table: Common triggers for 0XC002004F
| Trigger | Likely cause |
|---|---|
| After Windows Update | Firewall rule disabled |
| After app uninstall | Corrupted registry key |
| After GPO change | Firewall or DCOM permissions |
| After network change | IPv6 disabled |
How to prevent this
Don't bother with disabling Windows Firewall completely — that opens security holes and can cause other RPC errors. Instead, use netsh advfirewall to only enable the rules you need.
Before applying Windows Updates, snapshot or backup the firewall rule state:
netsh advfirewall export "C:\backup\firewall_rule_%date:~-4,4%%date:~-10,2%%date:~-7,2%.wfw"
Then if the update breaks RPC, you can import the backup quickly:
netsh advfirewall import "C:\backup\firewall_rule_20250315.wfw"
Also, set a scheduled task to check the RPC service daily. If it's not running, have it restart automatically. I've seen services fail after some cumulative updates, and catching it early saves a call.
One more thing: if you're in an Active Directory environment and this happens on multiple servers, check your Group Policy for the "Windows Firewall: Allow inbound remote administration exception" setting. That should be Enabled. If it's Not Configured, local policies might override it.
That's it. Most of the time it's a firewall rule or a stopped service. The registry and DCOM stuff is rarer, but you'll know what to look for now.
Was this solution helpful?