RPC_NT_CALL_FAILED_DNE (0XC002001C) – RPC endpoint not found fix

Cause #1: The RPC service (RpcSs) isn't running or is set to manual

This error pops up when a program—like a backup agent, a management tool, or a custom app—tries to call a remote procedure on a Windows server, but the RPC endpoint mapper can't find the target. The error text is literal: the RPC call failed because the endpoint doesn't exist (DNE). Most times, the problem is that the Remote Procedure Call (RPC) service on the target machine hasn't started.

I've seen this happen after a server reboot, a Windows Update, or when someone accidentally disabled the service. The RPC service is set to start automatically by default, but I've found it gets changed to Manual after certain security scans or manual cleanup scripts. If it's Manual, it only starts when something asks for it—but if the request comes before the service kicks in, you get 0xC002001C.

How to check and fix it

1. Press Win + R, type services.msc, and hit Enter. The Services window opens.
2. Scroll down to Remote Procedure Call (RPC). Double-click it.
3. In the Properties window, look at the Startup type. It should be Automatic. If it's Manual or Disabled, change it to Automatic.
4. Check the Service status. If it's not Running, click Start. After clicking Start, the status should change to Running within a few seconds.
5. Click Apply, then OK.
6. Also check RPC Endpoint Mapper (it's usually just below RPC in the list). This service depends on RpcSs. Set it to Automatic as well, and start it if it's stopped.

After making these changes, try the operation that gave you the error again. If it works, you're done. If not, move to cause #2.

Cause #2: Windows Firewall (or a third-party firewall) is blocking RPC dynamic ports

RPC uses a well-known port (135) for the endpoint mapper, but the actual communication happens over dynamic ports in the range 49152-65535 (on Windows Vista and later, or 1024-5000 on older systems). Many firewalls block these dynamic ports by default. When the client connects to port 135, the endpoint mapper says "talk to port 54321," but the firewall drops that connection. The client then reports error 0xC002001C because the endpoint never answered.

I've seen this most often when someone configures a firewall rule that only allows port 135, forgetting the dynamic range. Also, some third-party firewalls (like McAfee or Symantec) have application-control features that block svchost.exe hosting the RPC service.

How to check and fix it

1. Open Windows Defender Firewall with Advanced Security (type wf.msc in Run).
2. Click Inbound Rules. Look for rules named Remote Service Management, Remote Event Log Management, or something with "RPC" in the name. If they're disabled, enable them by right-clicking and selecting Enable Rule.
3. If you don't see those rules, you might need to create one. Click New Rule on the right. Choose Port, then TCP. In the Specific local ports field, type 135. Click Next. Choose Allow the connection. Apply it to Domain and Private profiles (not Public unless needed). Name it RPC Endpoint Mapper. Click Finish.
4. Now add the dynamic port range. Create another new rule, again Port > TCP, but this time type 49152-65535 (or 1024-5000 if your server is older than Windows 8 or 2012). Allow the connection, apply to Domain/Private, name it RPC Dynamic Ports.
5. If you're using a third-party firewall, open its control panel and look for application or service rules. Make sure C:\Windows\System32\svchost.exe is allowed to listen on TCP ports. Also check that the firewall isn't blocking C:\Windows\System32\RpcSs.dll (though that's unusual).

After adding these rules, restart the RPC Endpoint Mapper service (right-click it in services.msc and choose Restart). Then test your application again. The error should be gone.

Cause #3: The target RPC application or service isn't registered (or is missing)

If the RPC services are running and the firewall is open, the next place to look is the application itself. Error 0xC002001C can mean that the program you're trying to contact—say, a custom service, a management agent, or a database listener—never registered itself with the RPC endpoint mapper. This happens when the service crashes during startup, fails to initialize, or wasn't installed properly.

For example, I once worked on a server where a backup agent kept failing with this error. The agent's service was running, but it had a corrupted config file. The agent started, but it couldn't register its RPC interface, so the endpoint mapper had no entry for it.

How to check and fix it

1. Open Event Viewer (eventvwr.msc from Run). Go to Windows Logs > Application. Look for errors happening around the same time you got the 0xC002001C error. Any red X events with source like Application Error, .NET Runtime, or the name of your failing program will give you clues.
2. Check if the target service is running. Open Services again and find the service for your application. Right-click it and select Properties. Note the Path to executable. Go to that folder and look for a log file or configuration file that might be malformed.
3. If the service is running but still causes the error, restart it: right-click > Restart. Watch Event Viewer for any new errors after the restart.
4. If the service won't start, try starting it manually from an elevated command prompt. Run cmd.exe as Administrator, then type: net start "YourServiceName". If you get an error, copy the error text—it'll tell you what's wrong.
5. As a last resort, uninstall and reinstall the failing application. This re-registers its RPC interfaces. For Microsoft components like SQL Server or Exchange, run the setup repair option.

After reinstalling or repairing, test your operation. If the error persists, you've got a deeper problem—maybe a dependency DLL missing, or a COM registration broken. That's rare, but it happens.

Quick-reference summary table

Start with cause #1. That's the fix I've used on hundreds of servers. If it doesn't work, move to #2, then #3. You'll almost never need to go past #2.