RPC_S_DUPLICATE_ENDPOINT 0x6CC: Fixes That Actually Work

Cause #1: A Service Registers the Same Port Twice (Most Common)

This is the one I see in the wild 80% of the time. Some service — usually a third-party app or a misconfigured Windows service — calls RpcServerUseProtseqEp with the same endpoint twice. The RPC runtime sees the duplicate registrations and throws 0x6CC right back at you.

The classic trigger? A service that auto-restarts after a crash but doesn't release its port properly. Or an app that loads two instances of itself on the same endpoint. Think of a database listener or backup agent that spawns a worker process which tries to bind to the same port as the main process.

How to pin down the offender

1. Open an elevated Command Prompt or PowerShell.
2. Run netstat -ano | findstr :135 (port 135 is the default RPC endpoint mapper). But the duplicate isn't always on 135 — it's usually a dynamic port in the 49152–65535 range. So you might need to grep for the specific port your app uses.
3. Cross-reference the PID with Task Manager or tasklist | findstr [PID].
4. If you see two PIDs listed for the same local address and port, that's your duplicate.

Direct fix

Kill the duplicate process, then restart the service that owns it. In most cases the service will re-register cleanly on the next start.

net stop "Service Name" && taskkill /F /PID [offending_pid] && net start "Service Name"

If it's a third-party app, check its config file for a hardcoded endpoint and change it to something else. Don't bother fiddling with DCOM settings yet — that's rarely the root cause.

Cause #2: Dynamic Port Range Collision with a Static Mapping

Windows reserves a block of dynamic ports for RPC. Starting with Windows Server 2008, that's 49152–65535. If you've manually assigned a static RPC port (like for firewall rules) that falls inside that range, you're asking for trouble. Some other service grabs that dynamic port, and your app tries to bind to it as a static endpoint. Boom — duplicate.

I've seen this exact mess with SQL Server or Exchange setups where someone set the RPC port to 51234 because it looked nice. It didn't stay nice for long.

Check your current RPC port range

netsh int ipv4 show dynamicport tcp

If the start port is below 49152, something's wrong. And if you've set static RPC ports, verify they're outside the dynamic range.

The fix

Either move your static RPC ports above 65535 (impossible) or below 49152 — but honestly, the cleanest fix is to remove the static mappings and let Windows handle dynamic ports. Then update your firewall rules to use the range instead of a single port.

netsh int ipv4 set dynamicport tcp start=49152 num=16384

That resets it to default. Then restart services that rely on RPC. If you absolutely need a fixed port, pick something in the 50000–65535 range that isn't yet reserved and make sure nothing else uses it. But be warned: you'll be back here eventually.

Cause #3: Stale Entries in the RPC Endpoint Mapper

This is the one people miss. The RPC endpoint mapper on the server keeps a database of registered endpoints. A service that crashed hard or didn't shut down cleanly might leave orphaned entries. When a new service starts and tries to register the same endpoint, the stale entry still exists — so the runtime screams duplicate.

The trigger here is usually an unexpected power loss or a forced reboot of a server that had dozens of RPC services running. I've also seen it after Windows Updates that didn't fully complete.

How to clear it

There's no command to just purge the endpoint mapper. The only reliable way is to restart the RPC services — but that's a cascading mess on a busy server. Here's the order that minimizes downtime:

1. Stop the service that's throwing the error.
2. Restart the RPC Endpoint Mapper service (DcomLaunch).
3. Restart your target service.

net stop "YourService" && net stop RpcEptMapper && net start RpcEptMapper && net start "YourService"

If the endpoint mapper won't stop (it's protected), you'll need to reboot the server. That's a last resort but it works. After the reboot, the stale entries are gone and your service should start clean. Just don't make a habit of it.

Quick-Reference Summary

If none of these work, run dcdiag on domain controllers — this error also shows up in AD replication when DNS records are duplicated. But that's a different article. Start here, and you'll solve 9 out of 10 cases.