RPC_S_SERVER_TOO_BUSY (0x000006bb) – Fix the busy RPC server

You're working on a client's Exchange 2016 server, and suddenly Outlook users start getting "The RPC server is too busy to complete this operation." The exact error code is 0x000006bb. Or maybe you're seeing it in the Application log on a Domain Controller running a heavy line-of-business app. It's not a network issue – the RPC server is there, it's just slammed.

Root cause: RPC thread pool exhaustion

The RPC runtime on Windows has a limited number of worker threads (default is around 100 on most servers). When all threads are busy handling requests – say, from Exchange or a database app – new incoming calls get rejected with this error. It's not a sign of a broken service; it's a capacity problem. The server can't queue requests, so it bounces them. I've seen this on Exchange 2013/2016 when the RPC client access array gets hammered during peak hours.

Fix: Increase the RPC thread count

You need to bump up the maximum number of RPC threads the server can use. This is a registry tweak, but it's safe if you stay within reasonable limits. Here's how I do it.

1. Open Registry Editor as Administrator. Go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RpcSs\Parameters. If the Parameters key doesn't exist, create it (right-click on RpcSs → New → Key).
2. Create a DWORD (32-bit) named MaxRpcThreads. Set it to 200 (decimal). For heavy load, you can go up to 300, but don't exceed 500 – that can cause CPU thrashing.
3. Create another DWORD named MaxRpcConnections. Set it to 1000 (decimal). This controls the total RPC connections allowed. Default is 500.
4. Reboot the server for the changes to take effect. A restart is mandatory – RPC service won't pick up new values dynamically.

Alternative fix (Exchange-specific): If this is an Exchange server, you can also increase the RPC Max Connections per Exchange client. Run this in Exchange Management Shell:

Set-RpcClientAccess -Server ExchServer01 -MaxConnections 5000

That raises the per-server connection limit from 1024 (default) to 5000. I do both registry and this Exchange tweak together.

What else to check if it still fails

• Port exhaustion: Run netstat -an | find ":135" to see how many RPC connections are active. If you see thousands of TIME_WAIT connections, you've hit the ephemeral port limit (max 16384 on older Windows). Increase it via HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters → MaxUserPort = 65534 (decimal).
• Service dependencies: Check if a misbehaving service is hogging RPC threads. Use tasklist /svc to see which processes have many RPC threads. I once found a custom app that leaked RPC handles – killing it fixed everything.
• Hardware limits: If your server has less than 4 GB RAM or a single CPU, adding threads won't help – you're CPU-bound. Upgrade the hardware first.
• Check for DCOM errors: Open Component Services (dcomcnfg) and look for components that aren't responding. DCOM launch failures can choke the RPC endpoint mapper.

If you've done all that and still get the error, you're likely dealing with a rogue application that's sending too many RPC calls per second. Use Performance Monitor with the RPC/Connections counter – if it spikes above 2000 sustained, you need to throttle the client app, not the server.

Real talk: I had a client last month whose entire print queue died because of this. Their print server was handling 300+ simultaneous print jobs, and RPC threads ran dry. Increasing MaxRpcThreads to 300 and adding more RAM fixed it. Print queue came back in minutes.

Skip the reboot unless you've made registry changes. And don't bother with the "Restart RPC service" suggestion you see online – that only clears the current thread pool but doesn't fix the root cause. The fix is always capacity scaling: more threads, more connections, or better endpoints.