RPC_NT_TYPE_ALREADY_REGISTERED 0XC002000D Fix

1. RPC Service Stuck — Restart It First

Nine times out of ten, the culprit here is the Remote Procedure Call (RPC) service itself getting into a bad state. It holds on to UUID registrations even after the app that registered them has crashed or exited. You'll see this error when starting a service, launching an app, or running a script that registers an RPC interface — especially after someone killed a process that previously registered the same UUID.

Don't bother checking event logs first. Just restart the service. Here's how:

1. Open an elevated Command Prompt or PowerShell.
2. Run net stop rpcss — note that this will stop dependent services (like DCOM Server Process Launcher). That's fine, they'll start back up.
3. Then net start rpcss to restart it.

Alternatively, use the Services snap-in (services.msc). Find Remote Procedure Call (RPC), right-click, choose Restart. Wait for the dependency services to come back online. That's it. If the error was due to a hung registration, it's gone now.

Pro tip: If you're on a production server, restart during a maintenance window. But honestly, this restart takes under 30 seconds, and the risk is lower than leaving the error unresolved.

2. Orphaned COM/DCOM Class Registry Entry

If restarting RPC doesn't fix it, the problem is almost certainly a stale COM class registration in the Windows Registry. Applications that register COM objects under the hood (like Exchange, SQL Server, or custom in-house apps) sometimes leave orphaned entries in HKCR\AppID or HKCR\CLSID. When you try to re-register the same UUID, the RPC layer sees it as already taken.

The fix: find and delete the orphaned registry key. But be careful — you need to identify the exact UUID from the error. If the error message doesn't show it, check the Application event log (Event ID 1000 or 7031 from the app). The UUID looks like XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX.

1. Open regedit.
2. Navigate to HKEY_CLASSES_ROOT\AppID and look for a key with that UUID as its name.
3. If found, back it up (right-click → Export), then delete it.
4. Also check HKEY_CLASSES_ROOT\CLSID for the same UUID — delete it too.
5. Restart the RPC service or reboot the server.

Real-world scenario: I've seen this after a failed installation of a third-party backup agent on Windows Server 2016. The installer registered a COM class, then rolled back but left the registry key. Every retry gave 0XC002000D. Deleting the orphaned AppID fixed it instantly.

3. Competing Application — Two Apps Want the Same UUID

Sometimes it's not a stale entry — it's two legit applications fighting over the same UUID range. This usually happens when you install two versions of the same software (like an older and newer Exchange Server role on the same machine) or when a custom app hard-codes a UUID that's already registered by the OS.

To check what's registered, use the built-in RPC endpoint mapper. Run this command in PowerShell:

rpcdump.exe | findstr /i "00000000-0000-0000-C000-000000000046"

Replace the UUID with the one from your error. If you see two entries with different process IDs, you've found the conflict. You can also use netstat -ano to find which PID is listening on port 135 (the RPC endpoint mapper port) and track down the offenders.

The fix: modify the UUID in one of the applications (if you control the code) or uninstall/reinstall the conflicting software. If it's a vendor app, contact support and tell them their UUID is conflicting with another service on your system. They'll have the fix — it's usually a hotfix or config change.

4. Corrupted RPC Database (Rare But Real)

If none of the above work, the RPC runtime's internal database might be corrupted. This is rare — I've only seen it twice in 14 years — but it happens after a hard crash or disk corruption. The symptom is that even after a clean restart, the error reappears immediately.

The nuclear option: rebuild the RPC database. On Windows Server 2012 R2 through 2019, this means running sfc /scannow and then DISM /Online /Cleanup-Image /RestoreHealth. Follow with a full system reboot. If that fails, a repair install of the OS is the final step — but honestly, backup and rebuild is faster at that point.

Quick-Reference Summary Table

Start with the RPC restart. Nine times out of ten, that's all you need. If not, move to registry cleanup. The other two are edge cases. You've got this.