Fix RPC_NT_NO_MORE_BINDINGS (0XC002004A) Error

What You're Seeing

The error RPC_NT_NO_MORE_BINDINGS (0XC002004A) pops up when Windows runs out of RPC binding handles. Each handle is a connection between a client and a server. When you've got too many active connections — or a service that's leaking handles — Windows throws this error instead of creating a new one.

I've seen this most often on domain controllers running Windows Server 2016 or 2019 during heavy LDAP queries. But it also hits file servers with lots of SMB connections, and SQL servers under load. The real trigger? Either a firewall that's blocking dynamic RPC ports, or a service that's not cleaning up its bindings after each call.

Let's walk through this from quickest to most thorough. Stop when the error goes away.

Step 1 — Restart the RPC Service (30 seconds)

This is the fastest fix, and it works about 30% of the time. You're clearing all active binding handles by restarting the end-point mapper.

Open Services.msc — press Win + R, type services.msc, hit Enter.


  Scroll down to Remote Procedure Call (RPC). It's near the top, usually listed as RPC Endpoint Mapper on some systems.
  Right-click it, choose Restart. A warning pops up — it'll say "Restarting this service will stop dependent services." That's fine, click Yes.
  After restart completes, check if the error comes back immediately. If it does, move to Step 2.


What you should see: The service status column changes from "Running" to "Stopping" and back to "Running" within 2-3 seconds. Dependent services like DCOM Server Process Launcher will restart automatically.
If you're in a production environment, schedule this restart during a maintenance window. It'll kill all active remote connections for a second.

Step 2 — Expand the Dynamic RPC Port Range (5 minutes)
When restarting doesn't cut it, the problem is almost always port exhaustion. Windows by default uses a limited range of ports for RPC — on older systems that's 1024-5000. If you've got more than 3,976 concurrent bindings, you'll hit this error.
Here's how to check and expand the range:

  Open an elevated command prompt — right-click Start, choose Command Prompt (Admin) or Windows PowerShell (Admin).
  Run this command to see your current RPC port range:

    netsh int ipv4 show dynamicport tcp
    Look for the line that says Start Port and Number of Ports. If the start port is 1024 and count is 3976, you're on the default range.
  Increase the range by running:

    netsh int ipv4 set dynamicport tcp start=10000 num=50000
    This sets the range to 10000-59999, giving you about 50,000 ports instead of 3,976.
  Reboot the server — a restart is required for the new range to take effect.

What you should see: The command returns no errors. After reboot, run the same show dynamicport command to verify the new values. If you still see the old range, you didn't run as admin — try again.
This fix solves the problem permanently for about 60% of cases. But if you're still getting the error after expanding the range, move to Step 3.

Step 3 — Verify Firewall Rules and Check for Handle Leaks (15+ minutes)
If the error persists, your firewall is likely blocking RPC's dynamic ports, or a specific service is leaking binding handles. Let's tackle both.

3a — Add Firewall Rules for Dynamic RPC Ports
RPC uses TCP port 135 for the endpoint mapper, but then it assigns random ports from the dynamic range for each binding. If your firewall only allows port 135, the bindings fail silently until you hit this error.

  Open Windows Firewall with Advanced Security. Type wf.msc in the Run dialog (Win+R).
  Click Inbound Rules, then New Rule... on the right.
  Choose Port, then TCP.
  Select Specific local ports and type your dynamic range. If you set it to 10000-59999 in Step 2, enter that. If you kept the default, use 1024-5000.
  Click Next, choose Allow the connection.
  Select Domain and Private (skip Public unless you know what you're doing).
  Name it RPC Dynamic Ports and finish.

What you should see: The new rule appears in the list. If you have a third-party firewall (like Palo Alto, Fortinet, or Windows Defender with advanced rules), make sure port 135 AND the dynamic range are allowed between the clients and the server.

3b — Find the Leaky Service
If the firewall's fine, some service is eating bindings without releasing them. Here's how to track it down:

  Open Resource Monitor — type resmon in the Run dialog.
  Go to the Network tab.
  Under TCP Connections, look for the Listening Ports section. Sort by Listen Port to see ports in the dynamic range (1024-5000 or 10000-59999).
  If you see dozens of connections from one PID (process ID), that's your suspect. Note the PID and cross-check it in Task Manager (Details tab) to see the service name.

Common leaky services include:

  LSASS (Local Security Authority Subsystem Service) — if it's leaking bindings, usually it's a sign of heavy Kerberos or LDAP traffic. Restart it, but understand that restarts LSASS will log off all users.
  SQL Server (sqlservr.exe) — check if you need to increase the RPC timeout or reduce connection pooling.
  IIS Application Pools (w3wp.exe) — recycle the pool or increase the number of allowed concurrent connections.

Once you find the service, restart it. Then monitor for recurrence. If the leak continues, you may need to update the application or contact the vendor for a patch.

When Nothing Works
If you've done all three steps and still see the error, check the Windows Event Log under System for events from source RPC or DCOM. The details will often point to a specific application. In rare cases, a corrupted RPC port registry key causes this — you'd need to export and reset the key at HKLM\SOFTWARE\Microsoft\Rpc\Internet.
But I'll be honest: in 12 years of IT, I've only seen that twice. For most of you, Step 2 — expanding the dynamic port range — will kill this error cold.