Fix MK_E_INTERMEDIATEINTERFACENOTSUPPORTED 0x800401E7

Quick answer: Your code or installer is calling QueryInterface on a COM object for an interface it doesn't implement. It's not a Windows bug — it's a version mismatch, a bitness mismatch, or a stale registration in HKCR. Find the CLSID, check the registry, and fix the registration.

I've seen this on everything from old VB6 line-of-business apps talking to Office to a Siemens SCADA package calling into an Access Runtime that was upgraded behind its back. The pattern's always the same: something asks a COM object for interface X, the object says "I only do Y", and OLE translates that into 0x800401E7. The MSDN docs call it MK_E_INTERMEDIATEINTERFACENOTSUPPORTED — "intermediate operation failed" is Microsoft's vague way of saying the object didn't expose the interface the caller needed to complete the operation.

Before you start uninstalling things, get the CLSID. Without it you're guessing. Use Process Monitor with a filter on RegOpenKey against HKCR\CLSID and reproduce the error. Or grab the debug output — most apps that bubble this up will log the GUID right before they crash.

Fix 1: Check the bitness first

This is the one people miss. If a 32-bit app is trying to load a 64-bit in-proc COM server (or vice versa), Windows will happily register it under the wrong hive and you get this error because the proxy/stub can't marshal the interface. Register it correctly:

REM For 32-bit DLL, run from SysWOW64
C:\Windows\SysWOW64\regsvr32.exe "C:\Program Files (x86)\Vendor\App\thing.dll"

REM For 64-bit DLL
C:\Windows\System32\regsvr32.exe "C:\Program Files\Vendor\App\thing64.dll"

Registry hives to check afterward: HKCR\Wow6432Node\CLSID\{GUID} for 32-bit and HKCR\CLSID\{GUID} for 64-bit. If both exist and point to different files, you've got your answer.

Fix 2: Re-register the COM server

Close every process that hosts the object. Task Manager, kill the app, kill any COM surrogate (dllhost.exe) hanging around.
Open an elevated command prompt.
Run regsvr32 /u on the DLL first to unregister, then regsvr32 again to register clean. Order matters — skipping the unregister leaves stale keys behind more often than you'd think.
If it's an EXE server, run thing.exe /regserver (or /RegServer, case varies) instead.
Restart the host app.

Fix 3: Repair the Visual C++ and .NET runtimes

Plenty of COM servers link against msvcrXX.dll or ship as managed shims. If the runtime is half-installed, the object loads but a vtable entry never gets resolved and QueryInterface quietly fails. Go to Settings > Apps, find every Microsoft Visual C++ Redistributable entry, hit Modify, then Repair. Do the same for .NET Desktop Runtime. It's boring, it works, and it takes ten minutes.

Fix 4: Enable Registration-Free COM for the app

If this is a legacy app you can't reinstall, sidestep the global registration entirely. Drop a manifest next to the EXE that declares the COM class locally:

<dependency>
  <dependentAssembly>
    <assemblyIdentity type="win32" name="Vendor.Thing" version="1.0.0.0" />
  </dependentAssembly>
</dependency>

You'll need a matching .manifest on the DLL with a comClass entry. This routes the lookup past HKCR and past whatever broken global state is causing 0x800401E7. Skip this if you're not comfortable editing manifests — you can break DLL loading fast.

Fix 5: Kill the type library collision

Run oleview.exe (from the Windows SDK) and browse the interfaces on the failing CLSID. If you see two type libraries with the same LIBID but different versions, that's your trigger. Two vendors shipped a thing.tlb with the same GUID. Uninstall the newer one, or use the vendor's side-by-side installer if they have one.

When the main fixes don't work

DCOM permissions: Open dcomcnfg, drill to Component Services > Computers > My Computer > DCOM Config, find the app, and check the Identity tab. Running as "The interactive user" when the caller is a service will fail this way every time.
AppContainer/UWP bridge: If a packaged app is calling into a desktop COM server, the CLSID needs to be exposed in the package manifest under desktop:Extension. Miss that and you get 0x800401E7 on launch.
Antivirus tampering: Some EDR products hook QueryInterface to block COM-based lateral movement. Whitelist the CLSID or the process and retry.
Nuclear option: Uninstall the vendor app completely, delete orphaned CLSID keys under HKCR\CLSID that point to files that no longer exist, then reinstall. Run reg query HKCR\CLSID\{GUID} /s first so you know what you're deleting.

Prevention tip

Pin your COM dependencies. If you're shipping an app that talks to Office or Access Runtime, ship the exact runtime version you tested against and don't let the vendor's auto-updater replace it silently. I've watched a single Office click-to-run update break a £40k invoicing system because Access Runtime bumped a minor version and dropped an interface. Version-pin, test upgrades in a ring, and keep a snapshot of the working HKCR\CLSID tree from a known-good box so you can diff it the next time 0x800401E7 lands on your desk.