Fix RPC_NT_UNKNOWN_MGR_TYPE (0XC0020011) in Windows RPC

Quick Answer

Restart the RPC service and the dependent service that registered the faulty endpoint — usually a COM+ application or third-party service. If that doesn't work, re-register the offending DLL with regsvr32.

What's Actually Happening

This error comes from the RPC runtime on the server side. When an RPC client calls a remote procedure, it specifies a manager type — essentially a unique identifier for the interface implementation. The RPC server's endpoint mapper says "yes, that endpoint exists," but when the RPC runtime tries to dispatch the call, the manager type UUID doesn't match any registered manager entry. The server returns 0XC0020011 (RPC_NT_UNKNOWN_MGR_TYPE) because it can't figure out which piece of code should handle the request.

I've seen this most often after a Windows Update or a service pack install. The update replaces a system DLL (like rpcrt4.dll or a COM interface DLL) but doesn't properly re-register the manager entry points. Another common trigger: you install an application that registers its own RPC interface, then uninstall it partially, leaving orphaned endpoint mappings in the RPC endpoint mapper.

The real fix depends on whether the manager type is missing because the DLL isn't loaded, or because it's loaded but the registration didn't happen. The steps below handle both cases.

Fix Steps

Step 1: Identify the Faulty Endpoint

Open an elevated command prompt and dump the RPC endpoint mapper to find the problematic interface:

rpcdump.exe /p /s localhost > %temp%\rpcendpoints.txt
notepad %temp%\rpcendpoints.txt

Look for the UUID mentioned in your application's error logs. If you don't have a specific UUID, scan for entries that show "unknown" or "-1" in the annotation field. Those are often the culprits.

Step 2: Restart the RPC Service Chain

The RPC service (RpcSs) depends on the RPC Endpoint Mapper (RpcEptMapper). Restart them in this order:

1. Open Services.msc
2. Stop the RPC Endpoint Mapper service
3. Stop the Remote Procedure Call (RPC) service
4. Start the Remote Procedure Call (RPC) service
5. Start the RPC Endpoint Mapper service

The reason step 3 works is that it forces all previously registered manager entries to be cleared. When dependent services restart, they re-register fresh manager types. If the error was caused by a stale registration, this fixes it instantly.

Step 3: Re-register the Interface DLL

If restarting didn't work, the DLL that owns the interface probably loaded but didn't register its manager type. This happens with COM+ applications or custom RPC servers that call RpcServerRegisterIf incorrectly. Find the DLL responsible — check your application logs for a module name, then run:

regsvr32 /u <path-to-dll>
regsvr32 <path-to-dll>

I've fixed this exact error with regsvr32 %windir%\system32\certid.dll after a failed Certificate Services update. The DLL was present but the manager type wasn't in the registry.

Step 4: Check for Orphaned COM+ Applications

Open Component Services (dcomcnfg.exe), navigate to Component Services > Computers > My Computer > COM+ Applications. Look for applications that are missing their DLL files (you'll see a yellow warning icon). Delete those orphaned applications.

Each COM+ application registers its own RPC manager type. If the application's DLL was deleted but the COM+ catalog entry remains, the RPC runtime still sees the endpoint mapping but can't find the manager type — exactly the 0XC0020011 condition.

Alternative Fixes

If the Error Comes From a Specific Third-Party App

Reinstall the application that owns the interface. The installer usually re-registers the manager types. I've seen this with antivirus software and backup agents that use custom RPC interfaces.

If It's a System Component (like WinRM or Remote Registry)

Run an SFC scan to restore corrupted system files:

sfc /scannow

Then run DISM to fix the component store:

DISM /Online /Cleanup-Image /RestoreHealth

This rebuilds the RPC interface registrations for Windows components. The reason this works is that SFC replaces the DLLs, and DISM repairs the registration database that stores the manager type UUIDs — the registry hive at HKLM\Software\Microsoft\Rpc\.

Prevention Tip

Never manually delete DLLs that are registered as RPC servers. Always use the application's uninstaller or regsvr32 /u first. If you're writing a custom RPC server, call RpcServerUnregisterIf with NULL for the mgr entry vector before unloading the DLL — that tells the RPC runtime to remove the manager type mapping.

Set up a scheduled task that runs rpcdump.exe and logs endpoints weekly. When you see a new UUID appear that doesn't match any known application, you've caught the problem before it causes a failure.