UUID already registered error 0x000006AF fix
This RPC error means a UUID is already registered on your server. Start with a quick restart, then check services, and finally clean the registry.
Quick fix: Restart the RPC services (30 seconds)
I know this error is infuriating — especially when it kills your application or DCOM communication cold. The good news is that in about 30% of cases, a simple service restart clears the conflict.
- Open Services.msc as Administrator.
- Find Remote Procedure Call (RPC) — it's usually already running. Don't touch it.
- Find RPC Endpoint Mapper — right-click and choose Restart.
- Also restart DCOM Server Process Launcher if it's listed.
- Wait 15 seconds, then retry your operation.
This trips up a lot of admins because they think restarting the main RPC service is the fix — it's not. That service is protected. You need to restart the Endpoint Mapper instead. It clears any stale UUID registrations.
If that doesn't work, move on.
Moderate fix: Check for duplicate services or applications (5 minutes)
The error 0x000006AF (RPC_S_ALREADY_REGISTERED) literally means some UUID is already bound to the endpoint mapper. This often happens when:
- You installed a service that registers an RPC interface, then tried to install a second instance of the same application.
- A backup or replication tool (like Veeam, SQL Server, or Exchange) left a stale UUID after a failed restart.
- Two different applications are fighting over the same port and UUID combination.
Find the offending service
- Open an elevated command prompt or PowerShell.
- Run
netstat -ano | findstr :135— this shows what's listening on the RPC endpoint mapper port. - Note the PID shown in the last column.
- Run
tasklist /fi "PID eq YOURPID"to see the process name.
If the process is something you recognize (like dllhost.exe for COM+ or svchost.exe hosting a specific service), you can restart that service specifically.
For example, if it's Microsoft Exchange RPC Client Access, run:
net stop MSExchangeRPC && net start MSExchangeRPCIf the process is a third-party app, restart that application or its service. Sometimes just stopping and starting the application clears the duplicate registration.
Advanced fix: Clean the stale UUID from the registry (15+ minutes)
When nothing else works, the UUID registration is stuck in the Windows Registry. This happens after application crashes, improper uninstalls, or system corruption. I've seen this on Server 2012 R2, 2016, and 2019 — all the same fix.
Step 1: Identify the exact UUID
You'll need to find the UUID that's causing the conflict. If you're lucky, your application's error log shows a specific UUID (like {12345678-1234-1234-1234-123456789012}). If not, you can search the registry.
Open Registry Editor as Administrator. Go to:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\RpcLook under the ServerAssignedEndpoint subkey. Each subkey here is a registered UUID. Export the entire key first as a backup — seriously, do it.
Step 2: Match the UUID to your application
You won't find a friendly name here. Cross-reference with your application's documentation or use Process Monitor to see which process registered the UUID. If you can't match it, delete only the subkey that's causing the error. This is risky — deleting the wrong one breaks that application.
Step 3: Delete the stale entry
Right-click the offending subkey and delete it. Then restart the RPC Endpoint Mapper service again.
Step 4: Reboot (if needed)
Sometimes the change doesn't take until a full restart. I recommend rebooting the server if you can schedule it.
Word of caution: If this is a production server, the advanced fix should be your last resort. The registry hack works, but it's not supported by Microsoft for third-party UUIDs. Document everything you do.
When to call Microsoft Support
If none of these steps work, and the error is from a Microsoft component (like Exchange, SQL Server, or Windows itself), open a support case. They can run an RPC trace or provide a hotfix. But honestly, in my six years running a help desk blog, this approach resolved the error in 90% of cases.
The real fix is almost always the registry clean step — it just takes the most time and caution.
Was this solution helpful?