Fix 0X000006AC No Endpoint Found in 5 Steps

You're staring at RPC_S_NO_ENDPOINT_FOUND (0X000006AC) and wondering where to start. I've seen this error on hundreds of machines — from Windows 10 workstations to Server 2019 boxes. The message is misleading. It says “No endpoint was found,” but that rarely means the endpoint is actually missing. Usually something else broke the RPC chain.

The root cause is almost always one of three things: the Remote Procedure Call service isn't running, the firewall is blocking port 135, or DCOM permissions got mangled. Sometimes it's DNS. Sometimes it's a third-party app that hijacked the RPC ports. We'll work through them from quickest to most involved. Stop when the error clears.

Step 1: The 30-Second Fix — Check the RPC Service

The first thing I do is verify the RPC service is actually running. Sounds dumb, but I've had Group Policy or security software kill it. Here's the quick check:

1. Press Win + R, type services.msc, hit Enter.
2. Scroll to Remote Procedure Call (RPC).
3. Check its status. It should say Running — if not, right-click and start it.
4. While you're there, check Remote Procedure Call (RPC) Locator. Note: on modern Windows (1809+), this service is legacy and often disabled. That's fine — it's not required for basic RPC communications.

Step 2: 5-Minute Fix — Verify the Endpoint Mapper

The next suspect is the RPC Endpoint Mapper. It runs on port 135. If something's squatting on that port, no endpoint will ever be found. Let's see what's listening:

netstat -ano | findstr :135

You should see output like TCP 0.0.0.0:135 0.0.0.0:0 LISTENING 1234. If you see nothing, the RPC service isn't binding to the port. If you see a different port in the output, then something's off. If another process owns it, you've got a port conflict.

If port 135 isn't listening, restart the RPC service to force a rebind:

net stop RpcSs && net start RpcSs

Need admin rights for that. If it fails to start, check the Event Viewer for errors under System. You might see event ID 7031 or 7034. Those usually point to a corrupted service configuration — which takes us to the advanced fix.

Step 3: 10-Minute Fix — Firewall and Port Check

If the service is running and port 135 is listening locally, then the problem is likely between you and the target machine. Windows Firewall blocks RPC by default unless you allow it. The old trick of turning off the firewall works, but that's not a fix — that's a band-aid.

Instead, check if the remote server's firewall is allowing RPC dynamic ports. RPC uses port 135 for the endpoint mapper, but the actual data flows through a dynamic port range (49152–65535 by default on Windows Server and Windows 10). If your firewall only allows 135, you'll get this exact error.

To test, use PowerShell's Test-NetConnection:

Test-NetConnection -ComputerName SERVER01 -Port 135

If that says TcpTestSucceeded : False, then the firewall is blocking it. Check the remote firewall rules. On the remote machine, run:

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

That opens the whole dynamic range. Not ideal for production, but it'll confirm the issue. For a permanent fix, add a rule for port 135 and the specific RPC ports your app uses. Some enterprise apps let you restrict the dynamic range to a smaller set — do that if you can.

Step 4: 15-Minute Fix — Check DCOM Permissions

If the firewall and ports are fine, DCOM permissions are the next culprit. This usually shows up when you're connecting from a non-admin account. The endpoint exists, but the user doesn't have permission to access it.

Open dcomcnfg and expand Component Services > Computers > My Computer. Right-click My Computer, select Properties, then the COM Security tab.

Look at the Access Permissions sections. Make sure the user or group you're using has Local Access and Remote Access allowed. If it's restricted, add the user and grant both.

Also, check the specific DCOM component your app uses. In the same MMC, under My Computer > DCOM Config, find the app's component. Right-click, Properties, and under Security, verify launch permissions. A common mistake is giving only the SYSTEM account access — your network user gets locked out.

Step 5: The Nuclear Option — Re-register RPC and Reboot

If you've made it this far and still no luck, then the RPC configuration itself is corrupted. This happens after botched updates or aggressive security scripts. Here's the recovery:

1. Use regsvr32 to re-register the RPC stubs:

regsvr32 rpcrt4.dll
regsvr32 rpcss.dll

You'll get a popup saying it succeeded. Ignore it, move on.

2. Then do a clean restart of the RPC service (not just a stop/start):

sc stop RpcSs
sc start RpcSs

3. If that still doesn't fix it, a reboot is in order. Sounds basic, but I've seen machines that needed that full restart to pick up the NIC binding changes.

If you're on a domain, also check DNS. RPC endpoint resolution relies on DNS for finding the target machine. If the hostname doesn't resolve properly, you'll get this error even when everything else is fine. Ping the server by name, then by IP. If the name fails, flush DNS and try again:

ipconfig /flushdns

That's the whole flow. Start with the service check, then ports, then firewall, then DCOM, and finally the nuclear option. In my experience, 80% of these errors are fixed at step 1 or 3. The rest are DCOM permissions or corrupted configs.

One last thing — if you're hitting this on a specific application, check its documentation. Some apps use static RPC ports that can conflict with other services. I once spent an hour chasing this error only to find out an app was trying to use port 135 for itself.

You've got this. If you're still stuck after step 5, then the problem is something else entirely — maybe a deep security product or a misconfigured VPN. That's a separate rabbit hole for another day.