Fix RPC_NT_CALL_FAILED 0XC002001B Error on Windows

This error shows up when a Windows RPC call times out or fails, often after a reboot or network change. You'll fix it by checking DCOM settings, firewall rules, and RPC services.

You're in the middle of a remote management session, or maybe a scheduled task that uses WMI or DCOM just fired, and instead of the expected result you get RPC_NT_CALL_FAILED (0XC002001B). This error typically pops up when a client tries to make a Remote Procedure Call to a Windows server, and the call either times out or gets rejected. I've seen it most often right after a server reboot when services take longer than usual to start, or when a firewall policy update accidentally blocks RPC dynamic ports.

The root cause is simpler than it looks. RPC is how Windows components talk to each other over the network. When the target machine doesn't respond within the timeout window, the client gives up and throws this code. That can happen for three reasons: the RPC service isn't running, the firewall is blocking the port, or DCOM permissions are misconfigured. You'd be surprised how many times it's just a service that didn't start because of a delayed network adapter.

Before You Start: Know Your Environment

Check whether both machines are on the same domain or workgroup. This matters because firewall rules and authentication settings differ. Also note the Windows Server version—I'm writing this with Server 2016, 2019, and 2022 in mind, but the steps work on Windows 10/11 too.

Fix Step by Step

Step 1: Verify RPC Services Are Running

Open Services.msc on the target server (the one that's supposed to receive the call). Look for these three services:

Remote Procedure Call (RPC)
RPC Endpoint Mapper
DCOM Server Process Launcher

All should be set to Automatic and currently Started. If RPC Endpoint Mapper isn't started, right-click it and select Start. After it starts, you should see the Status column change to Started. If it fails to start, that points to a deeper issue—check the System event log for related errors.

Step 2: Test Basic RPC Connectivity

From the client machine, open Command Prompt as administrator and run:

wmic /node:"SERVERNAME" /user:DOMAIN\USER /password:* process list brief

This forces an RPC call. If it hangs or gives a different error, you'll know it's a network issue. If it returns a list of processes, RPC is working at a basic level.

Step 3: Check Firewall Rules for RPC

Windows Firewall has a built-in rule group called 'Remote Service Management' that includes RPC. Make sure it's enabled. On the target server:

Open Windows Defender Firewall with Advanced Security.
Click Inbound Rules.
Scroll to find rules with 'Remote Service Management' or 'Remote Event Log Management'.
Right-click each and choose Enable Rule if they're off.

After enabling, try the RPC call again. If that works, you're done. If not, the rule might not cover the dynamic ports RPC uses.

Step 4: Configure RPC Dynamic Port Range

RPC uses a random port range (49152-65535) by default. Some firewall policies block that entire range. You can narrow it down:

On the target server, open Registry Editor (regedit).
Go to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc\Internet.
If there's no 'Internet' key, create it. Then create a DWORD value named 'Ports' and set it to something like 50000-50100.
Create another DWORD called 'PortsInternetAvailable' and set it to 1.
Reboot the server or restart the RPC service for the change to take effect.

After reboot, you must add a firewall rule to allow TCP ports 50000-50100 inbound. Don't forget that step, or you'll lock yourself out.

Step 5: Adjust DCOM Permissions

If the error appears for a specific application, DCOM permissions might be too restrictive. Open Component Services (comexp.msc), navigate to Component Services > Computers > My Computer > DCOM Config. Find the component that's failing, right-click it, and select Properties. Under the Security tab, check the Launch and Activation Permissions. Make sure the user account making the call has at least Local Launch and Local Activation permissions. If not, add them.

Step 6: Check for Timeout Issues

Sometimes the RPC call just needs more time. On the client machine, create or modify this registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Rpc

Add a DWORD value named ConnectionTimeout and set it to a decimal value like 120 (seconds). Default is around 120, but some environments need more. After setting it, reboot the client. I've seen this fix calls that were borderline timing out.

Step 7: Verify Authentication Settings

If the target server uses Kerberos and the client isn't domain-joined, RPC fails. Make sure both machines can resolve each other's names via DNS. Run nslookup SERVERNAME from the client. If it doesn't return the correct IP, fix DNS first.

If It Still Fails

After all that, if the error persists, turn to the Event Viewer on the target server. Look under Windows Logs > System for events from source 'Service Control Manager' or 'RPC'. The event details often give a more specific reason. Also check if third-party security software like antivirus or HIPS is interfering—temporarily disable it to test.

One more thing: make sure the RPC service isn't crashing. Open a command prompt and run sc query rpcss. If the state shows STOPPED, the service is crashing, which points to a corrupted DLL or a driver issue. In that case, run sfc /scannow to repair system files.

The pragmatic fix is often a combination of enabling the right firewall rules and giving DCOM permissions to the correct user. Don't overthink it—work through the steps in order, test after each one, and you'll find the culprit.