Fixing RPC_S_INTERFACE_NOT_FOUND (0X000006DF)

What's Actually Happening Here

The error 0X000006DF (RPC_S_INTERFACE_NOT_FOUND) shows up when a client process asks for a specific RPC interface that the server endpoint mapper doesn't have registered. The interface might've been unregistered by a failed install, a corrupt update, or a service that crashed mid-operation. You'll see this most often after a Windows Update rollback or when using tools like dcomcnfg. The real trigger is the endpoint mapper database getting out of sync with what's actually running.

30-Second Fix: Restart the RPC Services

This is the first thing to try. The RPC services cache their interface registrations in memory. A restart forces them to re-read from the registry. Open a command prompt as Administrator and run:

net stop RpcSs && net stop RpcEptMapper && net start RpcEptMapper && net start RpcSs

That stops both the RPC Service and the Endpoint Mapper, then starts them in the correct order — Endpoint Mapper first, then RPC Service. The && chains them so if one fails, the whole thing halts. If you see "service name is invalid" or similar, the services are already stopped; skip to the next step.

This works about 40% of the time. The reason: a stuck RPC endpoint mapper entry gets cleared when the service restarts. The interface the client is asking for was registered by a process that's still running, but the endpoint mapper lost track. Restarting it forces a fresh handshake.

5-Minute Fix: Re-register RPC DLLs and Check DCOM Permissions

If the quick restart didn't work, the interface registration itself might be missing from the registry. This happens after a partial Windows Update where some DLLs got updated but the registration didn't take. Run these commands in an Admin command prompt:

regsvr32 /s rpcrt4.dll
regsvr32 /s rpcss.dll
regsvr32 /s rpcproxy.dll
regsvr32 /s ole32.dll
regsvr32 /s oleaut32.dll

The /s flag suppresses success messages — you'll only see errors if something's wrong. These DLLs contain the core RPC and COM infrastructure. Re-registering them writes or repairs the HKEY_CLASSES_ROOT\CLSID entries that the endpoint mapper reads.

Now, the often-missed part: DCOM launch permissions. If a service account doesn't have rights to launch the interface's COM object, you'll get this error despite everything being registered correctly. Open dcomcnfg from the Run dialog, go to Component Services > Computers > My Computer > DCOM Config. Find the specific component that's failing (look in Event Viewer under System for Event ID 10010 — it lists the CLSID). Right-click it, go to Properties > Security tab, and under Launch and Activation Permissions, choose Customize. Give the NETWORK SERVICE and LOCAL SERVICE accounts Local Launch and Local Activation rights.

This fix works when the error consistently happens with the same application or service. The key insight: default permissions changed after a cumulative update, and the service account lost access it previously had.

15+ Minute Fix: Clean the RPC Endpoint Mapper Database and Rebuild

When the above fails, the endpoint mapper database itself is corrupt or has stale entries that won't clear. This is rare but real — I've seen it after a failed Exchange Server or SQL Server install that left orphaned RPC interface IDs.

Step 1: Identify the interface GUID. Look in Event Viewer under Windows Logs > System. Filter by source "DCOM" or "RPC" and look for the error. It'll show something like:

The server {GUID} did not register with DCOM within the required timeout.

Write down that GUID. That's the interface that's missing.

Step 2: Check if the interface's COM object is still registered. Open Regedit and navigate to:

HKEY_CLASSES_ROOT\CLSID\{GUID}

If it's missing entirely, the component was uninstalled or the registration was deleted. If it's there, check HKEY_CLASSES_ROOT\CLSID\{GUID}\InprocServer32 or LocalServer32 — the default value should point to an existing DLL or EXE. If the path is wrong or the file is gone, that's your problem.

Step 3: If the registry entry is fine but the error persists, you need to force the endpoint mapper to flush its cache. Stop the RPC services, then delete the endpoint mapper's dynamic data:

net stop RpcSs
net stop RpcEptMapper
reg delete "HKLM\SYSTEM\CurrentControlSet\Services\RpcEptMapper\Parameters" /f
net start RpcEptMapper
net start RpcSs

The Parameters key holds the runtime data the mapper uses. Deleting it removes stale interface mappings. The mapper recreates it on next start. This is the nuclear option — it wipes all dynamic registrations, so any service that registered an interface dynamically (not from a static CLSID) will need to be restarted. Run net start | find /i "service" to list services and restart any that depend on RPC, like net start Spooler if it's stopped.

Step 4: As a last resort, reinstall the related Windows component. For example, if the interface belongs to Windows Update, run:

DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannow

Then reboot. This fixes corrupted system files that might prevent the interface from being registered again. The reason this is last: it's slow and only helps if the issue is file corruption, not just a registration hiccup.

When to Give Up and Rebuild

If you've done all three fixes and the error persists, the interface you need is likely from a third-party application that was improperly uninstalled. The cleanest path is to uninstall and reinstall that application using the vendor's official uninstaller tool — not just the Programs and Features entry. Many vendors (Autodesk, SAP, Oracle) provide cleanup utilities that remove leftover RPC registrations. Use those.

On Windows Server, also check if the Remote Procedure Call (RPC) service's Log On tab uses NT AUTHORITY\NetworkService — if it got changed to something else, the endpoint mapper can't authenticate. Reset it to NetworkService and restart.