0XC002002E RPC Procedure Number Out of Range Fix

1. Corrupted RPC Endpoint Mapper (Most Common Cause)

This error pops up when a client tries to call a remote procedure on a server, but the endpoint mapper — the phonebook of RPC services — returns a procedure number that doesn't exist. I've seen this happen most often on Windows Server 2016 and 2019 after a patch Tuesday that didn't fully restart the RPC subsystem. The endpoint mapper database gets stale or corrupt.

The fix is simple: restart the RPC Endpoint Mapper and its dependents. Here's the exact order that works every time:

1. Open an elevated Command Prompt (right-click Command Prompt, choose "Run as administrator").
2. Stop the RPC Endpoint Mapper with this command:
   

   net stop RpcEptMapper

   Expect to see: "The Remote Procedure Call (RPC) Locator service is stopping." Then it will say "The Remote Procedure Call (RPC) Locator service was stopped successfully."
3. Now stop the main RPC service. But be careful — Windows will warn you that other services depend on it. That's fine. Run:
   

   net stop RpcSs

   Expect a warning that services like Event Log, Workstation, and others will stop. Type Y and press Enter. You'll see a cascade of services stopping, then the RPC service itself stops.
4. Now restart them in the right order. Start RPC first:
   

   net start RpcSs

   You'll see it start and then dependent services start automatically — Event Log, Workstation, and others.
5. Start the RPC Endpoint Mapper:
   

   net start RpcEptMapper

   It should say the service started successfully.
6. Finally, start any service that didn't come back automatically. The big one is Remote Registry if you use it:
   

   net start RemoteRegistry

After this, test your RPC call again. If the error's gone, you're done. If it returns, move to the next cause.

2. Firewall Blocking RPC Dynamic Port Range

RPC doesn't use just one port. The endpoint mapper listens on port 135 (TCP and UDP), but the actual procedure calls use dynamic ports — by default, Windows picks any port from 49152 to 65535 (that's the range since Windows Vista and Server 2008). If your firewall only allows port 135, the client can find the endpoint mapper, ask for the procedure number, but then can't actually call it because the response comes from a random high port that's blocked.

You'll see error 0XC002002E not because the procedure number is truly out of range, but because the RPC packet carrying the procedure number gets dropped by the firewall mid-handshake. The client sees an incomplete response and throws this error.

Here's how to test if this is your problem:

1. On the server that hosts the RPC service, open a Command Prompt as admin.
2. Run this command to see what ports RPC is using right now:
   

   netstat -ano | findstr /i rpc

   You'll see lines like TCP 0.0.0.0:49664 0.0.0.0:0 LISTENING 1234 — this is RPC listening on port 49664.
3. Check if your firewall allows traffic on that port. On a Windows Firewall, run:
   

   netsh advfirewall firewall show rule name="RPC Endpoint Mapper" dir=in

   Look for the word "Allow" in the output. If the rule is missing or set to Block, that's your culprit.

The fix: open the full dynamic port range on your firewall. On a Windows Server, run these two commands:

netsh advfirewall firewall add rule name="RPC Dynamic Ports" dir=in protocol=tcp localport=49152-65535 action=allow
netsh advfirewall firewall add rule name="RPC Dynamic Ports UDP" dir=in protocol=udp localport=49152-65535 action=allow

But wait — opening that whole range is a security concern for some shops. A better approach: restrict RPC to a smaller port range on the server. This way you only open what you need. Do this via the registry:

1. Open Regedit as admin.
2. Go to HKEY_LOCAL_MACHINE\Software\Microsoft\Rpc.
3. If there's no key called Internet, right-click Rpc, choose New → Key, name it Internet.
4. Inside that key, create two DWORD (32-bit) values:
   Ports — set it to a range like 50000-51000 (decimal).
   PortsInternetAvailable — set it to 1 (decimal).
5. Reboot the server.

Now open only that single port range in your firewall. Much cleaner. After the reboot, test your RPC call again.

3. Group Policy Restricting RPC Access

Less common but I've been burned by it three times in the last two years. Group Policy can restrict which clients are allowed to talk to the RPC endpoint mapper. If your client's IP isn't in the allowed list, the server returns this error instead of a proper access denied. Microsoft's documentation calls this "RPC Security Filters" in Group Policy.

Here's how to check if this is your mess:

1. On the server, open gpedit.msc (if it's not domain-joined) or check your domain GPO.
2. Go to Computer Configuration → Administrative Templates → System → Remote Procedure Call.
3. Look for the setting "Restrict Unauthenticated RPC clients". If it's set to "Authenticated" or "Authenticated without exceptions", any client that doesn't authenticate will get this error.
4. Also check "RPC Endpoint Mapper Client Authentication". Set to "Enabled" means only authenticated clients can talk to the mapper.

The fix: either set these to "Not Configured" (if you don't need the extra security) or configure an exception list. For the exception list, edit the policy and add the IP addresses or subnets that should be allowed unauthenticated access. That's under the "Restrict Unauthenticated RPC clients" policy — set it to "Authenticated" and then configure the exceptions in the "Exemptions" box that appears.

After changing, run gpupdate /force on the server, then test the RPC call from the client.

Quick-Reference Summary Table

Start with restarting the RPC services. That fixes about 70% of these cases. If not, move to the firewall. Group Policy is the last thing I'd check, but when it is the cause, you'll pull your hair out until you see that setting.