Fix RPC_S_UNKNOWN_IF 0x6B5 (Interface Unknown)

RPC_S_UNKNOWN_IF (0x6B5) hits when a Windows service tries to call an RPC interface that isn't registered. Often after updates or corrupt registry. Fixing involves checking RPC service and re-registering DLLs.

You're in the middle of a quiet afternoon, and suddenly a client's line-of-business app throws up a dialog with RPC_S_UNKNOWN_IF (0x000006B5)—"The interface is unknown." I've seen this exact error on Windows Server 2016 and 2019 boxes, usually right after a patch Tuesday or when some third-party backup software decides to mess with DCOM settings. The trigger is almost always a service trying to call a remote procedure call (RPC) interface that the server just doesn't have registered anymore. One time, a client's print server started failing all queue operations with this error because a Windows Update rolled back a printer driver component that had registered an RPC interface.

What the heck is "interface unknown"?

RPC is how Windows services talk to each other over the network. Think of it as a phone system: each service has an extension (the interface GUID). When your app dials that extension, it expects the service to pick up. RPC_S_UNKNOWN_IF means the phone number is no longer in service—the remote server doesn't have that interface registered in its RPC endpoint mapper. The error code 0x6B5 is just the hex representation.

Common culprits:

A service stopped or crashed before it could register its interfaces.
A recent Windows Update or hotfix removed or re-registered a DLL, breaking the interface mapping.
Misconfigured DCOM permissions—the calling process lacks rights to query the endpoint mapper.
Firewall or network issue that blocks RPC dynamic ports, but that usually gives a different error (0x6BA), so don't chase that unless you're sure.

The fix—step by step

Don't go reinstalling apps yet. Try these in order. I've fixed 9 out of 10 cases with the first two steps alone.

Check that the RPC service is actually running. Open Services (Win+R, type services.msc, Enter). Look for Remote Procedure Call (RPC) and DCOM Server Process Launcher. They should be running, not just set to Automatic. If they're stopped, start them and set startup to Automatic. If they won't start, you've got bigger problems—see the end of this article.
Re-register the RPC runtime DLLs. This is the classic fix after updates. Open an elevated Command Prompt (right-click cmd, Run as administrator). Run these one at a time:
```
regsvr32 /i rpcrt4.dll
regsvr32 /i rpcss.dll
regsvr32 /i dssenh.dll
```
You might see a few errors—ignore them unless they all fail. Then restart the RPC service or reboot.
Check for orphaned interface registrations. Sometimes a service leaves a stale registration in the registry. Use the DCOM console (dcomcnfg) to browse to Component Services > Computers > My Computer > DCOM Config. Look for anything with a yellow warning icon or a GUID that matches the failing interface. If you find the app's component, right-click, Properties, and ensure the Identity tab says "The interactive user" (or a valid service account). If it's set to a specific user that's been deleted, that'll cause this.
Verify the DCOM endpoint mapper permissions. In dcomcnfg, right-click My Computer, Properties, COM Security tab. Under Access Permissions, click Edit Default. Ensure Everyone or Distributed COM Users has Local Access and Remote Access allowed. If someone tightened these down, that's your problem. I literally fixed a client's issue by adding "Remote Desktop Users" to that list.
Re-register the specific component that's failing. If you know which app or service is throwing the error (check Event Viewer under Windows Logs > System, filter for Source "DCOM" or "Service Control Manager"), you can re-register it. For example, if it's a COM object, run:
```
regsvr32 /i <path-to-dll>
```
If it's an exe that registers on first run, just restart it.

Still failing? Here's what to check next

If you've done all that and the error persists, you're in the 10% that needs deeper digging.

First, check the exact interface GUID in the error. If your error message gives you something like {12345678-1234-1234-1234-123456789012}, search for that in the registry under HKEY_CLASSES_ROOT\Interface. Does the key exist? If not, the DLL that should register it is missing. Use a tool like Process Monitor to see which process fails to load that DLL. I've seen antivirus quarantine a DLL that looked suspicious—check your AV quarantine.

Second, look at the RPC Endpoint Mapper itself. Sometimes the service is running but its endpoint mapper database is corrupt. You can clear it by stopping the RPC service and deleting the \RPC folder under C:\Windows\System32\RPC? Actually, don't do that—that folder is part of the system. Instead, just reboot in Safe Mode, which reloads the endpoint mapper fresh. If it works in Safe Mode, a third-party service is stepping on it.

Third, check if the error is happening on the client side or server side. If it's a client app, try running it on a different machine. If it only fails on one machine, it's a local DCOM configuration issue. If it fails everywhere, the server's remote interface is the problem.

Last resort: run sfc /scannow from an elevated command prompt. It checks system file integrity and can restore corrupted RPC DLLs. I've had it fix weird DCOM errors that nothing else touched.

If you've truly hit a wall, the nuclear option is to recreate the DCOM security registry keys. Export HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole, then delete it and reboot. Windows will rebuild it with defaults. Back up the key first, because this wipes any custom DCOM settings you had. I did this once on a Server 2012 box after a botched security template—worked like a charm, but only after spending a full afternoon trying everything else.

Remember, this error isn't a death sentence. Nine times out of ten it's a hiccup after an update or a service not starting. Work through the steps, and you'll have it back before your coffee gets cold.