MK_E_CONNECTMANUALLY 0x800401E0: Moniker Fix

Quick answer for advanced users: Register the COM component with regsvr32 or check DCOM permissions via dcomcnfg — the moniker is failing because the class isn't registered or the service isn't running.

Why this happens

I ran into this last year at a client who had a print queue management app. Every time they tried to automate a report, they got 0x800401E0. The error means the moniker — a reference to a COM object — can't connect automatically. It's waiting for you to manually hook it up. Nine times out of ten, the COM class isn't properly registered, the service that hosts it is stopped, or the DCOM permissions are locked down. Think of it like calling someone's phone but you have the wrong number — the system knows what you want but can't dial it.

Fix steps (try these in order)

1. Find which COM object is failing. Check the application's event logs or use Process Monitor. In my client's case, it was a script referencing Wingdings.PrinterQueue. The error message usually shows the CLSID or ProgID.
2. Register the DLL or OCX. Open an admin command prompt and run regsvr32 path\to\component.dll. If you don't know the path, search for the CLSID in the registry under HKEY_CLASSES_ROOT\CLSID. For my client, we re-registered the printer driver DLL and it fixed it immediately.
3. Start the dependent service. Many COM objects are hosted by a Windows service. Open services.msc and look for services like DCOM Server Process Launcher, Remote Procedure Call, or the specific service tied to the app. If it's stopped, start it and set it to automatic.
4. Check DCOM permissions. Run dcomcnfg, go to Component Services > Computers > My Computer > DCOM Config. Find the component (by CLSID or name), right-click Properties > Security. Under Launch and Activation Permissions, edit to include NETWORK SERVICE and LOCAL SERVICE with Local Launch and Local Activation allowed. Had a client whose antivirus had nuked these permissions — took two hours to trace it back.

Alternative fixes if the main one fails

• Reinstall the application — if registration keeps failing, the app's installer is corrupt. Uninstall, clean the registry with something like CCleaner, then reinstall.
• Manually create the registry entries. For advanced users: export a working machine's CLSID key and import it on the broken one. I've done this for a legacy accounting app that wouldn't register its COM component.
• Use SysInternals RegMon to see exactly what registry key the app is failing on. Once I found a typo in a path — a missing backslash — that caused the whole thing to break.

Prevention tip

Don't let antivirus or system cleaners strip DCOM permissions. Keep a snapshot of your HKEY_CLASSES_ROOT\CLSID key after installing any COM-heavy software. If you're scripting COM objects, always wrap calls in error handling that logs the CLSID — saves you hours later. And for the love of Pete, never use a GUID in your code — use ProgIDs; they're human-readable and easier to debug.