RPC_S_PROTOCOL_ERROR (0X000006C0) Fix on Windows
This RPC protocol error usually hits during remote WMI connections or DFS replication. The fix is almost always a corrupted RPC endpoint mapper or a firewall block. Here's how to squash it fast.
When Does This Error Show Up?
You're trying to run a remote WMI query from Server A to Server B using wmic or PowerShell's Get-WmiObject, and boom — RPC_S_PROTOCOL_ERROR (0X000006C0). Or maybe you're setting up DFS Replication between two file servers and the replication wizard throws this exact code. I've seen it most often on Windows Server 2016 and 2019, but it happens on Windows 10 too when you enable winrm and try to connect to a remote machine.
The trigger is almost always a corrupted RPC endpoint mapper (EPM) or a firewall rule that's blocking dynamic RPC ports. The error message itself is vague — "An RPC protocol error occurred" — which is why people waste hours chasing ghosts.
Root Cause
The RPC endpoint mapper runs on TCP port 135. When the client connects, it asks the EPM: "Hey, what port does WMI use?" The EPM replies with a dynamic port (usually in the 49152-65535 range). If that dynamic port is blocked by a firewall, or if the EPM service (RPCSS) is hung or has a corrupt endpoint database, you get 0X000006C0.
Another common cause: the DCOM settings on the target machine are locked down tight. If HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole\EnableDCOM is set to N, the RPC call fails before it even starts. Or if the Remote Registry service is disabled, the WMI provider can't register its endpoints.
Bottom line: the EPM can't hand back a valid port, or the port it hands back isn't reachable. That's your problem.
The Fix Step-by-Step
- Verify DCOM is enabled on the target machine. Open Regedit and check
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole\EnableDCOM. It must beY. If it'sN, change it toYand reboot. - Restart the RPC Endpoint Mapper service. Run
services.msc, findRemote Procedure Call (RPC)(that's the endpoint mapper), right-click and choose Restart. Yes, it'll break other services for a few seconds, but this clears a corrupt endpoint cache. Do this on both machines. - Open the dynamic RPC port range in Windows Firewall. Run this as admin on the target machine:
This opens the high ports. If you're on a domain, push this via GPO instead.netsh advfirewall firewall add rule name="RPC Dynamic Ports" dir=in action=allow protocol=TCP localport=49152-65535 - Check if WinRM is the culprit. Sometimes the error comes from WinRM, not raw RPC. Run
winrm quickconfigon both machines and ensure the WinRM listener is running. If you get an access denied, check theTrustedHostslist —winrm set winrm/config/client @{TrustedHosts="*"}if you're in a test environment. - Flush the RPC endpoint cache manually. Stop the RPCSS service (it'll stop the endpoint mapper), delete the file
C:\Windows\System32\RpcEpMap.db, then restart the service. This rebuilds the endpoint database from scratch. Do this only if step 2 didn't work. - Verify the remote machine's firewall allows RPC administration. Add this rule if missing:
Then test withnetsh advfirewall firewall add rule name="RPC Administration" dir=in action=allow protocol=TCP localport=135Test-NetConnection -ComputerName TARGET -Port 135from the client.
Still Failing? Check These
- Third-party antivirus. I've seen McAfee and Symantec Endpoint Protection block RPC dynamic ports even when Windows Firewall is open. Temporarily disable the AV and retest. If it works, add an AV exception for the RPC port range.
- Network team. Corporate firewalls between VLANs often block the dynamic RPC range. Talk to your network team. Ask them to open TCP 49152-65535 for RPC between the affected subnets.
- IPv6. If IPv6 is enabled but not routed properly, the RPC client might try to connect via IPv6 and fail. Disable IPv6 on the client's network adapter temporarily to test:
netsh interface ipv6 disable. - Kerberos vs NTLM. If the machines aren't domain-joined or the Kerberos ticket is expired, RPC falls back to NTLM which can trigger this error. Run
klist purgeon the client, then re-authenticate withrunas /user:DOMAIN\Admin cmdand retest.
That's it. Start with DCOM check and the firewall rule — 9 times out of 10, that's the fix. The rest is edge cases. Good luck.
Was this solution helpful?