Fixing RPC_S_NOT_CANCELLED (0x00000722) on Windows Server

Cause #1: Hung RPC call in IIS or SQL Server

This is the one I see most often. You're running a web app or SQL Server query that kicks off a remote procedure call to another machine, and that call just sits there. The calling thread tries to cancel the RPC operation — maybe your app has a timeout or a cancel button — but the RPC runtime says "Nope, can't cancel it, thread's still running." That's your 0x00000722.

I had a client last month whose payroll app hung every Friday because a stored procedure on SQL Server was making an RPC call to a legacy accounting system that was offline. The thread couldn't cancel, so the whole IIS worker process locked up. The event log showed 0x00000722 followed by a W3WP crash.

How to fix it

• Increase the RPC timeout on the caller side. In IIS, check your web.config for executionTimeout under httpRuntime. Set it higher than the expected RPC call duration — but not infinite. 90 seconds is a safe bet.
• In SQL Server, check remote query timeout (default 600 seconds) and remote proc trans settings. If the remote server is unreliable, lower the timeout so it doesn't hang forever.
• If the remote machine is dead, fix that first. Make sure both servers can resolve each other's hostnames and that firewall ports 135 and dynamic RPC ports (1024-65535) are open.
• Restart the RPCSS service on the server that's making the call — but only during a maintenance window, because this kills all active RPC connections.

net stop RpcSs && net start RpcSs

If you can't restart the service, kill the stuck thread via Task Manager (find the PID in event log, then taskkill /F /PID <PID>). But that's a band-aid, not a fix.

Cause #2: DCOM timeout mismatch

Another common trigger: DCOM calls between servers where the client's timeout is shorter than the server's processing time. The client gives up and tries to cancel, but the server is still chewing on the request. The RPC runtime refuses to cancel because the server hasn't responded yet — classic 0x00000722.

I've seen this with custom COM+ components talking to remote databases. The component calls a method on a remote object, the method takes 45 seconds, but the DCOM timeout is set to 30 seconds. Boom — stuck thread.

How to fix it

• Check DCOM timeout settings in Component Services (dcomcnfg). Navigate to the specific COM+ application, right-click Properties, go to the Advanced tab, and increase the Idle Timeout and Call Timeout values.
• Alternatively, tweak the registry: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole. Look for CallTimeout (in milliseconds). If it doesn't exist, create a DWORD. Set it to 60000 (60 seconds) or longer. Reboot or restart the affected services.
• Also check HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RpcSs\Parameters. The RPC_MaxRpcSize key can cause weird timeouts if set too low.

Cause #3: Anti-virus or security software interfering

Less common, but I've seen it twice this year. Some AV suites hook into RPC calls to scan them, and if the scanner hangs or takes too long, the RPC runtime can't cancel the thread. The error shows up randomly, often after an AV update.

How to fix it

• Temporarily disable the AV on the server making the RPC call. If the error stops, you've found the culprit.
• Add an exception for RPC-related processes: svchost.exe (the RPCSS host), dllhost.exe (COM+), and w3wp.exe (IIS).
• If you're using Windows Defender, check if Controlled Folder Access is blocking RPC temp files.

Quick-reference summary table

If none of that works, you're dealing with something deeper — maybe a corrupt RPC endpoint mapper. Netmon traces or Wireshark captures can show you exactly where the call stalls. But start with these three, because they cover 90% of the cases I've fixed in the field.