Fix RPC_S_CALL_IN_PROGRESS (0x000006FF) Error

Quick answer

Kill the stuck RPC call by restarting the RPC service (Start > Run > services.msc, find Remote Procedure Call (RPC), right-click, restart). If that fails, reboot the machine.

What's actually happening here is your thread tried to start a new RPC call while the previous one was still active. The RPC runtime won't let that happen because it can't handle two calls on the same thread. This is by design — RPC is single-threaded per thread context. The fix is usually to wait for the first call to finish, but if it's stuck (like waiting on a network timeout or a hung server), you need to cancel it.

Why you see this error

This happens with old Windows apps, especially those using DCOM (Distributed COM) or custom RPC interfaces. Common triggers:

An app that makes two RPC calls in quick succession from the same thread without waiting for the first one.
A server that went offline during an RPC call, leaving the thread waiting forever.
Misconfigured DCOM permissions on Windows Server 2016, 2019, or 2022 that cause calls to hang.
A bug in the app's own RPC handling — it doesn't check return codes properly.

The error code 0x000006FF maps to RPC_S_CALL_IN_PROGRESS. The RPC runtime raises it synchronously. Your app gets it and usually crashes or shows a message box.

Fix steps

Step 1: Identify the hung thread

Open Task Manager (Ctrl+Shift+Esc), go to the Details tab. Find your app's process. Look at the CPU column — if it's pegged at 25% or 50% with a single thread stuck, that's your culprit. Then run tasklist /fi "PID eq YOURPID" to confirm.

Step 2: Kill the stuck call

The quickest way to break the deadlock is to restart the RPC service. This kills all active RPC calls on the machine, including the stuck one.

net stop rpcss && net start rpcss

Run that as Administrator. Your app will probably fail right after, but that's fine — you cleared the blockage. Restart the app.

Step 3: If step 2 doesn't work, reboot

Yes, this is boring. But sometimes the RPC service gets into a state where it won't restart cleanly. Reboot the machine. On a server, schedule it for off-hours.

Step 4: Check for DCOM timeouts

If the error keeps coming back, the problem is likely a DCOM timeout. The default timeout for DCOM calls is 60 seconds. If the remote server doesn't respond in time, your thread hangs. Bump it up or down depending on your network.

reg add "HKLM\SOFTWARE\Microsoft\Ole" /v DefaultCallTimeout /t REG_DWORD /d 30000 /f

This sets the timeout to 30 seconds (value in milliseconds). Test it. If you still get the error, the remote server is probably offline or unreachable.

Step 5: Fix the app's code (if you control it)

If you're the developer, the real fix is to never make two RPC calls from the same thread without waiting. Use RpcAsyncCancelCall or check RpcAsyncGetCallStatus before starting a new one. Or move calls to worker threads.

Alternative fixes

Disable the app's use of RPC — if the app has a config option to use named pipes or local files instead, try that. Not always possible.
Update the app — many old apps have this bug fixed in later versions. Check the vendor's site.
Use a scheduled task to restart the RPC service every hour if the error is intermittent and the app can handle it.

Prevention tip

Don't let your app make multiple RPC calls on the same thread. If you must, use asynchronous RPC with proper completion handling. Or switch to a different IPC mechanism like gRPC or named pipes. On a server, set DCOM timeouts to something reasonable (30-60 seconds) and monitor for hung calls with rpcping or WMI.