You're in the middle of a remote management session, maybe running a PowerShell command against a server or kicking off an application install via SCCM, and then it hits you: RPC_NT_CALL_CANCELLED (0XC0020050) - The RPC was canceled. The operation just dies, no graceful error, just that cryptic hex code. I've seen this most often on Windows Server 2016 and 2019, especially when a long-running task—like a WMI query or a remote registry edit—exceeds the client's RPC timeout. But it's not just timeouts. It can also appear when a user closes the console window mid-call, or when a security product like antivirus or host firewall terminates the RPC connection because it thinks it's malicious.
Root cause in plain English
At its core, RPC (Remote Procedure Call) is how Windows components talk to each other across the network. When you call a remote function, your client sends a request and waits for a reply. The RPC_NT_CALL_CANCELLED error means that the call was actively cancelled—not that it timed out, not that the server crashed, but that something sent a cancel signal. That something could be your own client app if it's designed to cancel long calls, the RPC runtime itself if it detects the connection is unresponsive, or even a network device like a load balancer that resets idle connections.
The trigger is often a firewall or security software monitoring RPC traffic. Since RPC uses dynamic ports (beyond the well-known 135), a strict firewall can drop the connection mid-call, and the client interprets that as a cancellation. Another common scenario: Kerberos tickets expiring during a lengthy operation. If the RPC call spans a long time and the ticket renewal fails, the call gets cancelled.
Step-by-step fix
- Check the event logs first. Open Event Viewer on both client and server. Look under Windows Logs → System for any RPC-related errors around the exact time of the failure. Also check Applications and Services Logs → Microsoft → Windows → RPC. The source and details there will tell you if it was a timeout, a security filter, or an app-level cancellation.
- Extend the RPC timeout. On the client machine, open a command prompt as admin and run:
reg add "HKLM\SOFTWARE\Microsoft\Rpc\Client\Timeout" /v Timeout /t REG_DWORD /d 300 /fThis sets the RPC timeout to 300 seconds (5 minutes). I recommend 300 instead of the default 120 because some WMI queries on large domains can take longer. Restart the client after this change.
- Verify dynamic port range. On the server, make sure the RPC dynamic ports are configured and not blocked. Run:
netsh rpc show configIf the range looks odd or is limited, set a proper range and add a firewall rule. For example:
netsh int ipv4 set dynamicport tcp start=49152 num=16384
netsh advfirewall firewall add rule name="RPC Dynamic Ports" dir=in action=allow protocol=TCP localport=49152-65535- Check Kerberos ticket lifetime. If the call runs longer than your Kerberos ticket lifetime (often 10 hours by default, but sometimes set to 60 minutes in hardened environments), the call can fail. Increase the ticket lifetime via Group Policy: Computer Configuration → Policies → Windows Settings → Security Settings → Account Policies → Kerberos Policy. Set both maximum ticket lifetime and renewal to a value that covers your longest operation.
- Disable IPv6 if you're not using it. RPC can sometimes fail over IPv6 due to missing routes or firewall rules. On both client and server, uncheck IPv6 on the network adapter (Properties → uncheck Internet Protocol Version 6) and reboot.
- Update network drivers and firmware. I've seen this error on older Broadcom and Realtek NICs that don't handle RPC traffic well, especially with jumbo frames. Check your NIC vendor's site for latest drivers.
If it still fails, check these
If the error persists after those steps, I'd dig into the application making the call. If it's a custom app, check its source code for any logic that might cancel the RPC call after a certain time. Also, test from a different client machine—if the error only happens on one machine, the problem is local, not server-side. Run a network capture (Wireshark) on both sides to see if the TCP connection gets reset by a firewall device, or if the server sends a cancel response itself. That will point you to the exact layer where the call gets cancelled.
One more thing: if you're using a VPN, try disconnecting and reconnecting. VPN tunnels can drop idle sessions, and RPC calls that cross them are prime candidates for this error. I've had that bite me more than once.