Fix RPC_NT_INTERFACE_NOT_FOUND (0XC002003C) on Windows Server

Cause #1: Missing or Corrupt COM/DCOM Registration

This is the number one reason you're seeing error 0XC002003C. Your app calls an RPC interface that's supposed to be registered on the server, but the GUID or its endpoint isn't there. I see this most often when someone installs a component (like a SQL Server instance or Exchange role) and it fails partway through, leaving a broken COM entry behind.

Here's the real-world trigger: You try to run Get-Service -ComputerName REMOTE-SERVER from PowerShell, or maybe an old VB6 app tries to call a remote object. The error pops right away — not after a timeout — because the interface literally doesn't exist on the target.

Check if the Interface is Registered

1. Open Registry Editor as Administrator on the server that's failing (or the server you're calling).
2. Go to HKLM\SOFTWARE\Classes\Interface. Look for the GUID from the error. Usually the event log shows it like {00000100-0000-0000-C000-000000000046}.
3. If the GUID is missing, the COM class isn't registered. If it's there but the ProxyStubClsid32 value points to a missing CLSID, that's the broken link.
4. Fix it by running the installer or component setup again. For example, msiexec /i C:\SQLServerSetup\sqlncli.msi /quiet. For Exchange, rerun the setup and choose "Repair".
5. After the fix, restart the Remote Procedure Call (RPC) service with net stop RpcSs && net start RpcSs. Then test your call again.

Expected outcome after step 4: The GUID appears under Interface, and its subkeys have ProxyStubClsid32 pointing to a real CLSID under HKLM\SOFTWARE\Classes\CLSID. The error should stop.

Cause #2: RPC Endpoint Mapper Has Cached Stale Data

This one's sneaky. The RPC Endpoint Mapper (port 135) keeps a cache of which interfaces are available on which dynamic ports. If a component or service crashes, its endpoint registration might not get cleaned up. Later, when your client connects and asks for that interface, the mapper says "port 49152" but nothing's listening there, and the client returns 0XC002003C.

I've seen this after a Windows Update restart where services restart out of order. The RPC service itself comes up before dependent services, so their endpoints aren't ready yet. By the time your client arrives, they might be registered, but the cache had stale data.

Flush the RPC Endpoint Mapper Cache

1. On the server, open Command Prompt as Administrator.
2. Run net stop RpcSs && net start RpcSs. This restarts the RPC service and clears its endpoint cache.
3. If the error persists, also restart the RPC Endpoint Mapper service (RpcEptMapper). But note: stopping RpcEptMapper will break other RPC calls for a moment. Do this: sc stop RpcEptMapper && sc start RpcEptMapper.
4. Wait 10 seconds after restarting, then try your original operation again.

Expected outcome: The client should now find the interface because the mapper has fresh data. If it still fails, move to Cause #3.

Cause #3: DCOM Permission Denied (Masked as Interface Not Found)

Sometimes Windows lies. The real issue isn't a missing interface — it's that the user account doesn't have access to launch or activate the COM object. The system returns 0XC002003C instead of the more honest E_ACCESSDENIED (0x80070005). I've seen this on Windows Server 2016+ when you use a domain admin but the DCOM permissions are stripped down for security.

Common scenario: You're running a backup agent under the SYSTEM account, and it tries to call a DCOM component on a remote server. The local SYSTEM account's token doesn't have the right privileges on the remote DCOM object.

Check DCOM Permissions

1. On the server, open dcomcnfg.exe (Component Services).
2. Go to Component Services > Computers > My Computer > DCOM Config.
3. Find your component by its CLSID or name. It might be under a GUID like {000209FF-0000-0000-C000-000000000046}. Look for a friendly name if available.
4. Right-click the component, choose Properties > Security.
5. Under Launch and Activation Permissions, click Edit. Make sure the user account running your client app is listed. If not, add it with Local Launch and Remote Launch permissions checked.
6. Click Apply, then OK.
7. Restart your client app and test again.

Expected outcome: The error should change to something else (like a timeout) or go away entirely. If it doesn't, you may need to check Access Permissions and Configuration Permissions on the same tab.

Quick-Reference Summary Table

If none of these work, check the application event log on the server for the specific CLSID or interface GUID. That's your real starting point. Also consider that the client might be calling a 32-bit interface from a 64-bit app — that'll give the same error. In that case, a registry reflection issue is at play, and you'll need to check both HKLM\SOFTWARE\Classes\Interface and HKLM\SOFTWARE\WOW6432Node\Classes\Interface.

One last thing: if you're on a domain, verify the RPC Port Range isn't blocked by Windows Firewall. A blocked port won't give 0XC002003C directly — you'll see a timeout — but sometimes the client reports it this way. Open the firewall rule for TCP 49152-65535 if you use dynamic RPC ports. Or configure a static port range in the registry at HKLM\SOFTWARE\Microsoft\Rpc\Internet. That's a deeper topic, but worth mentioning.