Fix RPC Name Service Unavailable 0XC002003F

What this error means (and what it doesn't)

The 0XC002003F error is RPC's way of saying "I can't find the name service." That service is the one that maps friendly names (like SERVER01) to IP addresses. When it's missing, any RPC call that needs a name lookup fails.

You'll see this when you try to access a remote computer's admin shares, open MMC snapshots like Computer Management pointed at another PC, or run scripts that use WMI over the network. It's not the same as RPC_S_SERVER_UNAVAILABLE (which is usually a network reachability issue). This one is specifically about name resolution.

The fix path below goes from a 30-second check to a full service reconfiguration. Try each step in order and stop when the error goes away.

Step 1: The 30-Second Fix — Test Your DNS

On the machine that's showing the error, open a command prompt as administrator. Press Windows key, type cmd, right-click Command Prompt, and select Run as administrator.
Run this command, replacing TargetComputerName with the name of the remote computer you're trying to reach:

nslookup TargetComputerName

If you get a response with an IP address, DNS is working for that name. If you get Non-existent domain or a timeout, that's your problem. The RPC service can't translate the name to an IP, so it throws 0XC002003F.

What to do if DNS fails:

Check that the remote computer's DNS record exists. On the DNS server, open DNS Manager and see if the host record is there. If it's missing, you can add it manually or run ipconfig /registerdns on the target machine.
If you're using a hosts file entry, verify it's correct. A typo there will cause exactly this error.

If DNS resolves correctly, move to Step 2. Don't skip it even if you think this isn't the issue — many times it's a combination of two things.

Step 2: The 5-Minute Fix — Check the Remote Registry and RPC Services

Even if DNS is fine, the RPC service on the target machine might be running under the wrong account or be stopped. Here's how to check.

On the remote computer (the one you're trying to connect to), open Services.msc. You can do this by pressing Windows key + R, typing services.msc, and hitting Enter.
Scroll down to Remote Procedure Call (RPC). Make sure its status is Running. If it's not, right-click and select Start.
Now find Remote Procedure Call (RPC) Locator. On modern Windows (Server 2012 and later, Windows 8 and later), this service is set to Manual by default and only starts when needed. That's fine. But on older systems (Server 2008, Windows 7), it might be required. If you're on an old OS, set it to Automatic and start it.
Also check DCOM Server Process Launcher (it's actually the RpcSs service in disguise). Its status should be Running too.

If all services are running, we move to the most common cause: the firewall blocking RPC dynamic ports.

Step 3: The 15-Minute Fix — Firewall Rules for RPC Dynamic Ports

RPC doesn't stick to a single port. It uses port 135 for the endpoint mapper, then negotiates a random high port (usually 49152–65535) for the actual data transfer. If your firewall only allows port 135, the initial connection works, but the name service lookup fails and you get 0XC002003F.

There are two ways to fix this. The easy way is to allow the RPC dynamic ports through Windows Firewall. The more restrictive way is to set a fixed port range. I'll show the easy way first.

Easy Firewall Fix (on the target machine)

Open Windows Defender Firewall with Advanced Security. Press Windows key + R, type wf.msc, and press Enter.
Click Inbound Rules in the left pane.
Click New Rule... on the right side.
Select Predefined, then from the dropdown choose Remote Service Management. Click Next.
Check all the rule boxes that appear (usually COM+, Remote Event Log, etc.), then click Next.
Select Allow the connection, click Next, then Finish.
Repeat the process, but this time choose Remote Event Log Management and Remote Volume Management if they weren't in the previous set.

If you're a domain admin, you can push these rules via Group Policy. But for a single machine, this manual method works fine.

If the error persists — set a fixed RPC port

Sometimes your firewall (not Windows Firewall, but a third-party one like Cisco ASA or Palo Alto) doesn't like dynamic ports. The better approach is to force RPC to use a specific port range.

On the target machine, open Registry Editor (regedit.exe).
Navigate to:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc\Internet

If the Internet key doesn't exist, right-click on Rpc, select New > Key, and name it Internet.

Under the Internet key, create two new DWORD (32-bit) values:
Name the first one PortsInternetAvailable and set its value to 1.
Name the second one UseInternetPorts and set its value to 1.
Now create a REG_SZ value called Ports (not a DWORD). Right-click, select New > String Value.
Set its value to something like 49152-49162 (a small range you'll open on the firewall).
Close Registry Editor and reboot the machine.

After the reboot, open that same port range (UDP and TCP) on your firewall, and also keep port 135 open. Then test your remote connection again.

When to call it a DNS issue (even if DNS looks fine)

If you've done all the above and still see 0XC002003F, check the remote machine's DNS suffix. A common scenario: you're trying to connect to SRV-01, but your DNS server only has SRV-01.corp.local. The RPC name service needs a fully qualified domain name.

Try connecting using the FQDN instead of the short name:

net use \\SRV-01.corp.local\C$ /user:DOMAIN\username

If that works, you've confirmed a DNS suffix problem. Fix it by adding the DNS suffix to your client's network adapter settings, or create a primary DNS suffix on the domain.

Last resort: check for time skew

Kerberos needs time synchronization. If the target machine's clock is off by more than 5 minutes from your client, RPC authentication fails with a misleading error. Run w32tm /query /status on both machines and check the offset. If it's large, reconfigure the time source.

That's rare, but I've seen it happen after a motherboard battery died. Don't spend hours on it unless you've ruled out everything else.

Stick to the steps in order. Most of the time, the firewall predefined rules fix it. If not, the fixed port range will.