RPC_E_INVALIDMETHOD (0X80010107) fix for DCOM errors

When this error shows up

You're on a Windows Server 2016 box running some legacy COM+ application — maybe an old accounting tool or a custom VB6 component. You launch it, and bam: RPC_E_INVALIDMETHOD (0X80010107). Or worse, you're trying to call a method on a remote COM object from a client machine, and it fails with the same hex code. The trigger is almost always a DCOM call over the network or within the same machine where the COM interface isn't properly registered or accessible.

Had a client last month whose entire print queue died because a COM component for their label printer wasn't registered correctly after a Windows update. Same error code.

Root cause

Inside Windows, COM uses a registry table that maps interface GUIDs to method dispatch IDs. When that mapping is missing or corrupted, the RPC runtime can't find the method you're calling. This happens when:

• The COM DLL wasn't registered with regsvr32 properly
• The 64-bit vs 32-bit mismatch — your app is 32-bit but the COM server is 64-bit or vice versa
• DCOM permissions block the calling user from accessing the interface
• The COM+ application is corrupted or its catalog is damaged

The fix — step by step

1. Identify the COM component. Check the application event log for an event ID 1000 or 1001 that lists the CLSID or ProgID. If you see something like {12345678-1234-1234-1234-123456789abc}, that's your target.
2. Re-register the DLL. Open an admin command prompt. If it's a 32-bit DLL on a 64-bit system, use the SysWOW64 version:

   %SystemRoot%\SysWOW64\regsvr32.exe /s "C:\Path\To\YourComponent.dll"

   For 64-bit:

   regsvr32 /s "C:\Path\To\YourComponent.dll"

   Don't skip the /s flag — silent mode avoids pop-ups that hang.
3. Verify the registration. Run regedit and go to HKEY_CLASSES_ROOT\CLSID\{your-GUID}. Check that InprocServer32 points to the correct DLL path. Also check HKEY_CLASSES_ROOT\Interface\{interface-GUID} for the ProxyStubClsid32 key.
4. Fix DCOM permissions. Open Component Services (dcomcnfg). Navigate to Component Services > Computers > My Computer > DCOM Config. Find your component by its CLSID or name. Right-click > Properties > Security. Under Access Permissions, click Edit. Add the user account that runs the app (usually NETWORK SERVICE or the app pool identity) with Allow Remote Access and Local Access. For Launch and Activation Permissions, do the same.
5. Reboot the component. In Component Services, under COM+ Applications, right-click your application and choose Shut Down, then right-click again and choose Start. This clears any stale cached interfaces.

If it still fails

Check the registry for a TreatAs subkey under the CLSID — this tells COM to use a different CLSID than what's registered. If it points to a missing component, that's your problem. Also check for a 32-bit vs 64-bit mismatch in the InprocServer32 path — seen this bite people using 32-bit Office on 64-bit Server 2019.

Last resort: use Procmon from Sysinternals. Filter for YourComponent.dll and look for registry KEY NOT FOUND or file PATH NOT FOUND errors. That'll show you exactly what the system is trying to load but can't find. Took me two hours on a client's terminal server once — turned out a temp folder cleanup had deleted the DLL, but the registry still pointed to it.

If none of that works, rebuild the COM+ application from scratch. Export the existing application as a MSI, uninstall it, then reinstall. That'll rewrite the registry entries clean.