Fix RPC_S_INVALID_ASYNC_CALL (0x0000077B) in Windows

Quick answer for advanced users

Reboot the client machine. If that's not an option, restart the RPC service and any dependent services (DCOM, WMI), then restart the app that triggered the error. If the error persists, check the client for stale RPC connections using rpcinfo -s on the server side and verify the RPC endpoint mapper is reachable on port 135.

Why you're seeing 0x0000077B

This error comes up when an application or service tries to use an asynchronous RPC call handle that's already been closed or was never properly initialized. The culprit here is almost always a timing issue — the client app makes an async call, the server responds, but the client's handle gets orphaned because of a network blip, a service restart, or the app itself handling the async context badly. I've seen this most often in custom .NET apps using WCF with named pipes, or in PowerShell scripts that hit remote WMI endpoints and then disconnect abruptly. On Windows Server 2019+ with DCOM hardening, this also happens when security settings mismatch between the client and server — the async handle gets invalidated because the RPC context can't negotiate security properly.

Step-by-step fix

1. Reboot the client machine. Sounds dumb, but it clears all stale RPC handles and resets the RPC runtime state. If you can't reboot, move to step 2.
2. Restart the RPC service and its dependents. Open an admin PowerShell and run:
   Restart-Service -Name RpcSs -Force
Restart-Service -Name DcomLaunch -Force
Restart-Service -Name Winmgmt -Force
   Then restart the application that threw the error.
3. Check the application code. If you have control over the app, look for async RPC calls that don't properly wait for completion before reusing the handle. The handle should be used only within a single async operation — don't cache it.
4. Verify network connectivity and firewall rules. The RPC endpoint mapper uses port 135 TCP. Make sure the client can reach the server on that port. Use Test-NetConnection: Test-NetConnection -ComputerName SERVER -Port 135
5. Check DCOM configuration. On the server, run dcomcnfg, go to Component Services -> Computers -> My Computer -> Properties -> Default Properties. Set “Default Authentication Level” to “Connect” and “Default Impersonation Level” to “Identify”. Apply and restart the services from step 2.

Alternative fixes if the main steps don't work

• Increase RPC timeouts. In the registry on the client, go to HKLM\SOFTWARE\Microsoft\Rpc. If it doesn't exist, create a DWORD called RpcTimeout and set it to 60000 (milliseconds). This gives async calls more time to complete before the handle is invalidated.
• Switch to synchronous RPC calls. If the async call isn't critical, change the app to use synchronous RPC. It's slower but way more reliable. In .NET, that means using ChannelFactory<T> with synchronous methods instead of async variants.
• Update the RPC runtime. On older Windows (Server 2008 R2, Win 7), install KB4489871 or the latest cumulative update. Microsoft fixed a race condition in the RPC runtime that could trigger this error.
• Use a different binding. Switch from named pipes to TCP/IP (ncacn_ip_tcp) in your RPC configuration. Named pipes are more prone to handle invalidation under load.

Preventing this from happening again

Don't reuse async RPC handles. Each async call should create a new handle or reset the existing one with RpcAsyncInitializeHandle before reuse. Also, set a reasonable timeout on the client side — I use 30 seconds for most internal apps. On the server, ensure DCOM is locked down but not overly restrictive — “Connect” authentication and “Identify” impersonation works for 99% of scenarios. And for the love of everything, don't let your devs cache RPC handles across threads without proper synchronization. I've had to fix that exact mistake more times than I care to count.