Fix RPC_S_CANT_CREATE_ENDPOINT (0x000006B8) on Server

When You See This Error

You're setting up a new role—say, DHCP or DFS—on Windows Server 2016 or 2019. The install fails. Or maybe an existing service like the RPC Endpoint Mapper just won't start. In Event Viewer, you spot RPC_S_CANT_CREATE_ENDPOINT (0x000006B8). This also shows up when a third-party app tries to register an RPC endpoint and some other process already owns the port.

What's Actually Happening

RPC (Remote Procedure Call) needs a TCP port—usually in the dynamic range 49152–65535—to listen for incoming calls. When it can't create an endpoint, it means that port is already taken. Could be another service, a stuck process, or a firewall rule that's reserving it. Windows doesn't always clean up port reservations gracefully after a crash or reboot.

The Fix: Step by Step

Step 1: Find the Blocked Port

Open Command Prompt as Administrator and run:

netstat -ano | findstr :135

This shows you what's listening on port 135 (the RPC Endpoint Mapper). If you see a PID (Process ID), note it. Also check the dynamic range:

netstat -ano | findstr :49152

Replace 49152 with any port your app or service reported. If nothing appears, it's likely a port in the ephemeral range that's reserved but not actively open. Use this to list all dynamic ports:

netsh int ipv4 show dynamicport tcp

Step 2: Kill the Stuck Process

If you found a PID in Step 1, check what it is:

tasklist /svc /FI "PID eq [PID]"

If it's a known service you can restart (like RpcSs), do that via Services.msc. If it's something weird like an orphaned svchost, kill it:

taskkill /PID [PID] /F

Then restart the RPC service:

net stop RpcSs && net start RpcSs

Step 3: Clear Port Reservation (if no PID found)

Sometimes the port is reserved by the OS but no process shows. You need to remove the reservation. Run:

netsh int ipv4 show excludedportrange tcp

If your dynamic port falls inside an excluded range, you have two options. Option A: restart the system (yes, a full reboot often clears these). Option B: change the dynamic port range to avoid the conflict:

netsh int ipv4 set dynamicport tcp start=50000 num=10000

This sets the range from 50000–59999, which usually avoids any pre-existing reservations. Reboot after changing it.

Step 4: Check Firewall Rules

Don't skip this. A misconfigured firewall rule can block RPC ports even if nothing else is wrong. Run:

netsh advfirewall firewall show rule name=all | findstr /i rpc

Look for rules that restrict port 135 or the dynamic range. If you see one that says "Block", either remove it or set it to "Allow" for the relevant profile.

Still Failing? Here's What to Check

Event Logs: Look in System and Application logs for events with source RPC or Wmi. They'll give the exact port that failed.
Third-party software: Antivirus or backup agents sometimes reserve RPC ports. Try disabling them temporarily to test.
Registry persistence: Check HKLM\SYSTEM\CurrentControlSet\Services\RpcSs and RpcEptMapper—make sure the start value is 2 (automatic).
Network binding: If you're running multiple NICs, RPC might bind to a dead interface. Try disabling all but one NIC under Network Settings, then restart RPC.

I've seen this error a dozen times on Server 2019 after a sudden power loss. The reboot + dynamic port range reconfiguration has never failed me. If you're still stuck after all that, check if the system has pending Windows Updates—I know it sounds basic, but a missing patch for RPC (KB5001401 or later) has been the culprit more than once.