Quick answer: Find the process holding the RPC thread (likely a hung service or app), kill it or restart the service, and the error clears. If it's persistent, check for network timeouts or third-party RPC hooks.
I've seen this error pop up in all sorts of places: SQL Server connection pools, Exchange management shells, even custom .NET apps that hammer an RPC endpoint. The message itself is straightforward—0XC0020049 means the thread you're on already has an RPC call in progress, so the runtime won't let you start another one. Windows does this to prevent reentrancy chaos, but when a call gets stuck (network hiccup, server never replies, deadlock in the RPC server), that thread stays locked forever. The worst part? The error often appears on a completely different thread than the one that's actually stuck, which is why it's so maddening to trace.
Most of the time, you're dealing with a hung RPC server or a client that didn't clean up its call. Here's how I'd attack it, in order.
Fix 1: Identify and kill the stuck process
First, you need to find which process is holding the RPC thread. Open Task Manager (Ctrl+Shift+Esc), go to Details, and look for processes with high CPU or a "Not Responding" status. But that's not always obvious. Better: use PowerShell to check for threads stuck in RPC wait states. Run this:
Get-Process | ForEach-Object { $_.Threads | Where-Object { $_.WaitReason -eq 'Executive' -and $_.ThreadState -eq 'Wait' } | Select-Object -First 5 @{N='Process';E={$_.ProcessName}}, Id }That's not perfect, but it gives you a starting point. More reliable: if you know which service or app triggers the error, restart that specific service. For example, if it's SQL Server:
Restart-Service MSSQLSERVER -ForceIf you don't know the culprit, check the System event log around the time of the error. Look for Event ID 1000 or 7031 that reference the process.
Once you've identified the process, kill it. Use Task Manager or:
Stop-Process -Name <processname> -ForceThen restart the service or app. In 80% of cases, that clears the stuck thread.
Fix 2: Restart the RPC service itself
If you can't pinpoint the process, restart the Remote Procedure Call (RPC) service. This is drastic, and yes, it will disconnect any active RPC clients—but it clears all stuck threads. Do it from an elevated command prompt:
net stop rpcss && net start rpcssNote: RPCSS is a protected service, so this might fail with "access denied" or hang. If it does, reboot the machine. Not glamorous, but it works.
Fix 3: Check for network-level causes
This error often appears when an RPC call times out due to network issues. If you're on a domain, check the client-server latency. A common trigger: a DNS misconfiguration causes the RPC endpoint mapper to time out, leaving threads hung. Run nslookup against the server name and verify it resolves to the right IP. Also, check if Windows Firewall is blocking RPC dynamic ports (49152-65535). If you're using a third-party firewall, make sure it allows those ports.
In one case I saw, a VPN client was intercepting RPC traffic, and the call never completed—the thread stayed in progress until the VPN session dropped. So if you're on VPN, try disconnecting and reconnecting.
Alternative: Increase RPC timeout (if it's a timeout issue)
If the error only happens during high load, you might be hitting the default RPC timeout. You can increase it via registry:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc\RpcProxyAdd a DWORD RPCPROXY_TIMEOUT and set it to, say, 60000 (milliseconds). But I'd only do this as a band-aid while you find the real cause—stretching timeouts masks deadlocks.
Prevention: Avoid reentrant calls and monitor thread health
The best way to keep this error from recurring: make sure your code (or the vendor's code) doesn't make nested synchronous RPC calls on the same thread. If you're writing a client, use an async pattern or a dedicated thread for long-running RPC calls. Also, set reasonable timeouts in your RPC bindings—use RpcBindingSetOption with RPC_C_OPT_CALL_TIMEOUT if you're in C/C++, or the equivalent in your framework.
On the server side, watch for deadlocks in your RPC server routines. I've seen custom RPC servers that hold a lock while waiting for a response from a downstream service—if that downstream service calls back, you've got a deadlock and a permanently stuck thread.
Finally, set up a monitoring script that checks for threads in a wait state for more than a few minutes. That's how you catch this before users do.