You're trying to connect to a remote Windows Server via MMC, or maybe you're running a script that calls a COM object on a remote machine, and instead of the expected response you get RPC_S_NOTHING_TO_EXPORT (0x000006DA). The full message reads "No interfaces have been exported." This usually happens right after you've installed a role or feature, or when you're trying to access a service that's registered with DCOM but the registration got mangled.
What's actually going on?
RPC (Remote Procedure Call) is how Windows lets one process talk to another, whether on the same machine or across the network. When a server wants to expose its functions, it "exports" interfaces—think of it as putting up a sign that says "I can do these things." The client asks the RPC endpoint mapper for a list of available interfaces. If the server hasn't registered anything, you get 0x6DA.
The root cause is almost always one of these:
- DCOM component not registered properly. The COM class ID exists in the registry, but the actual DLL or EXE never called
CoRegisterClassObject. - Windows Firewall (or a third-party firewall) is blocking RPC dynamic ports. The endpoint mapper (port 135) responds, but when the client tries to connect to the actual RPC interface on a random high port, it gets nothing.
- The RPC service or DCOM Server Process Launcher (DcomLaunch) is stopped or disabled. Without DcomLaunch, no COM objects can be activated.
- A recent restart didn't complete properly. Sometimes services fail to register their interfaces during a rushed reboot.
I've seen this error most often on Windows Server 2019 and 2022 after installing the RSAT tools or after a failed Windows Update that left the DCOM configuration half-baked.
The fix, step by step
Start with the quick checks, then move to the heavier stuff. Skip the registry editing if the service restart works—don't go poking around if you don't have to.
Step 1: Restart the RPC and DCOM services
Open an elevated PowerShell or Command Prompt on the server and run:
Restart-Service -Name RpcSs, DcomLaunch -Force
Wait 30 seconds, then try your connection again. If it worked, you're done. If not, move on.
Step 2: Check if the RPC service is set to automatic
Sometimes third-party security tools set these services to manual or disabled. Run:
Get-Service RpcSs, DcomLaunch | Select Name, StartType, Status
Both should show Automatic and Running. If not, set them:
Set-Service -Name RpcSs -StartupType Automatic
Set-Service -Name DcomLaunch -StartupType Automatic
Start-Service RpcSs, DcomLaunch
Step 3: Reset the RPC endpoint mapper
This one's a bit niche, but I've seen it fix 0x6DA when the endpoint mapper cached a stale entry. From an elevated command prompt:
net stop rpcWait a few seconds, then:
net start rpcI know it sounds too simple, but it's worth a shot before you go re-registering everything.
Step 4: Re-register the problematic COM component
If you know which component is throwing the error, you can re-register it. For example, if it's the WMI service, you'd run:
mofcomp c:\windows\system32\wbem\root\cimv2But the generic approach is to re-register all DCOM components in the system. This is heavy-handed, but it works:
for %i in (*.dll) do regsvr32 /s %iRun that from C:\Windows\System32 and from C:\Windows\SysWOW64 (if you're on 64-bit). It takes a few minutes, and you'll see some errors pop up—that's normal, just let it finish.
Step 5: Check firewall rules for RPC dynamic ports
If the error only happens when you connect from another machine, the firewall is your enemy. The client needs access to port 135 plus the dynamic port range (usually 49152–65535). You can either open the whole range (not great) or restrict RPC to a specific range using netsh:
netsh int ipv4 set dynamicport tcp start=50000 num=1000
netsh int ipv4 set dynamicport udp start=50000 num=1000
Then add firewall rules for ports 50000–50999. This is what you'd do on a domain controller where you can't open the whole range.
Step 6: Verify DCOM registration in the registry
If you're still stuck, the component's CLSID might exist but the LocalServer32 or InprocServer32 points to a missing DLL. You'd need to find the CLSID from the error details (check Event Viewer under Windows Logs > System, look for RPC events).
Then open Regedit and navigate to:
HKEY_CLASSES_ROOT\CLSID\{your-clsid}\InprocServer32Make sure the default value points to the correct file. If it's wrong, fix it. If the file doesn't exist, you've got a broken install—reinstall the software that provided that component.
Still failing?
If you've gone through all six steps and the error persists, check Event Viewer for the exact RPC event ID. Look for events with source RPC or DCOM around the time of the failure. The event details often tell you which interface is missing.
Also, check if the target machine is actually running the service you're trying to reach. That sounds obvious, but I've spent an hour chasing 0x6DA only to find the service had stopped after a crash. Restart the service and try again.
And if you're dealing with a clustered server, make sure the RPC service is running on all nodes. I've seen a cluster where only the active node had RPC running, and any connection to the passive node would fail with this exact error.
Last resort: reboot the server. I hate saying that, but sometimes Windows just needs to restart its RPC stack cleanly. I've had it fix 0x6DA more than once when nothing else did.