Fix RPC_X_NO_MORE_ENTRIES (0X000006EC) exhausted auto handles

I know this error is infuriating — one minute your application's working, the next you're staring at RPC_X_NO_MORE_ENTRIES (0x000006EC) and wondering why Windows can't find any RPC servers. This tripped me up on a Server 2019 box serving a legacy ERP app. The root cause is almost always a service state glitch or port exhaustion. Let's fix it.

The fix: restart RPC services in the right order

Don't reboot yet. Run PowerShell as Administrator and execute these commands in sequence:

# Stop dependent services first
Stop-Service -Name RpcEptMapper -Force -ErrorAction SilentlyContinue
Stop-Service -Name RpcSs -Force -ErrorAction SilentlyContinue

# Wait five seconds — give the kernel time to release handles
Start-Sleep -Seconds 5

# Start in reverse order: RpcSs first, then RpcEptMapper
Start-Service -Name RpcSs
Start-Service -Name RpcEptMapper

# Check status
Get-Service RpcSs, RpcEptMapper | Format-Table Name, Status, StartType

If they're both Running after this, test your app. In my case, it worked immediately. The trick is stopping the Endpoint Mapper (RpcEptMapper) before the RPC service (RpcSs). Doing it the other way can orphan the binding table.

Still broken? Try a full restart of both plus the DCOM Server Process Launcher:

Stop-Service -Name RpcEptMapper, RpcSs, DcomLaunch -Force
Start-Sleep 5
Start-Service -Name DcomLaunch
Start-Service -Name RpcSs
Start-Service -Name RpcEptMapper

Why this happens

When Windows runs out of available RPC server entries for auto handles, the underlying cause is usually one of three things:

1. Service restart corruption — the RPC service restarted unexpectedly (maybe from a GPO push or patch) but left the endpoint mapper in a dirty state. Auto handles try to bind to any available RPC server, get nothing, and throw 0x000006EC.
2. Port exhaustion — dynamic RPC ports (default range 1024–5000 on older systems, 49152–65535 on modern Windows) are all consumed. The server can't allocate a new listening port, so the RPC server list appears empty.
3. EP mapper registry corruption — rare, but happens if a disk write stalls during service startup. The HKLM\SYSTEM\CurrentControlSet\Services\RpcEptMapper parameters get mangled.

The restart forces the endpoint mapper to rebuild its binding table from scratch. That's why the order matters — RpcSs owns the RPC runtime, and RpcEptMapper depends on it to register endpoints.

Less common variations: port exhaustion and registry fixes

Check dynamic port range

If the service restart didn't help, run this to see if you've blown through your port pool:

netstat -an | findstr /i 49152-65535 | measure | %{$_.Count}

# Or for older systems:
netstat -an | findstr /i 1024-5000 | measure | %{$_.Count}

If the count is over 15,000 (close to the max of 16,384), you're exhausting the range. Use netsh int ipv4 show dynamicport tcp to see your current range. Expand it with:

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

This matches the default on Server 2016 and later. On old Server 2008 R2 boxes, the default was only 1024–5000 (3977 ports). That's tiny — double it to 10000.

Reset the EP mapper registry (nuclear option)

If you suspect corruption, export the key first, then delete and recreate:

reg export "HKLM\SYSTEM\CurrentControlSet\Services\RpcEptMapper" C:\backup_rpc_ept.reg
reg delete "HKLM\SYSTEM\CurrentControlSet\Services\RpcEptMapper" /f
sc create RpcEptMapper type= kernel start= demand binPath= "system32\svchost.exe -k RPCSS"

Then reboot. This is drastic — I've only needed it twice in six years. Do a system state backup first.

Prevention

Stop this from happening again:

• Monitor dynamic ports — set up a perfmon counter for TCPv4\Connections Established and alert when usage hits 70% of your max ports.
• Increase the port range proactively on any server running RPC-heavy apps (Exchange, SQL Server, file servers). Use the netsh command above. I set num=16384 on every production box.
• Stagger service restarts — if you apply patches or GPO changes that restart RPC, do it during a maintenance window and bounce RpcSs and RpcEptMapper together as shown above.
• Check for RPC timeouts — if your app makes rapid-fire RPC calls (like a monitoring tool polling every second), it can exhaust handles. Add a small delay between calls or use connection pooling.

That's it. You'll see this error maybe once a year if you keep ports healthy. When it does pop up, you know the drill.