MK_E_NOOBJECT (0x800401E5): COM Moniker Error Fixed

I know this error is infuriating. You double-click a file, or try to open something in Word or Excel, and Windows just shrugs with a hexadecimal middle finger: MK_E_NOOBJECT (0x800401E5) - No object for moniker. No file opens. No explanation. Just a dead end.

Here's what's happening under the hood. "Moniker" is COM-speak for a name that points to an object — a file, a handler, a registered library. When Windows tries to resolve that name and comes up empty, you get 0x800401E5. The object it wants simply isn't registered, or the thing meant to register it is broken.

The good news: this is almost always a registration problem, not a corrupted Windows install. Let's walk through the three causes I've seen in the wild, in order of how often they show up.

Cause 1: Broken file associations (the usual suspect)

This one hits people after a botched uninstall. You removed Office, or a PDF reader, or some image editor, and the shell kept the association pointing at a COM handler that no longer exists. Now every time you double-click a .docx or .pdf, Explorer tries to resolve a moniker for a handler that's been unregistered. Boom — 0x800401E5.

The classic trigger: you uninstall Adobe Acrobat Reader, then double-click a PDF. Windows still thinks Acrobat is the handler, tries to load its COM object, fails, and throws the error. Same story if you uninstalled LibreOffice and .odt files still point at it.

Fix: reset the association

1. Press Win + I and go to Apps > Default apps.
2. Scroll to the bottom and click Reset all default apps (Windows 11) or Reset to the Microsoft recommended defaults (Windows 10). This nukes every association back to stock.
3. Reassign your preferred apps one at a time. Don't bulk-assign — that's how you got here.

If you only want to fix one extension, right-click the file, choose Open with > Choose another app, pick the right program, and tick "Always use this app." That rewrites the association and clears the stale moniker.

Skip third-party "association fixer" utilities. They're mostly adware and they overwrite the same registry keys Windows already manages.

Cause 2: Unregistered or corrupted COM DLLs

Some component — often shell32.dll, actxprxy.dll, or an Office DLL — got unregistered. A bad Windows Update, a half-finished install, or a third-party registry cleaner can all do this. The object the moniker points to exists on disk, but the registry has no entry saying "this is what you load."

You'll usually spot this one because the error shows up across multiple file types, not just one. If .docx, .xlsx, and .pdf all throw 0x800401E5, you're looking at DLL registration, not a single bad association.

Fix: re-register the core shell and OLE DLLs

Open Command Prompt as Administrator and run these one at a time. Each line re-registers a DLL that COM depends on:

regsvr32 /i shell32.dll
regsvr32 /i browseui.dll
regsvr32 /i actxprxy.dll
regsvr32 /i oleaut32.dll
regsvr32 /i shdocvw.dll
regsvr32 /i mshtml.dll

You should see a "DllRegisterServer succeeded" popup for each. If any of them fail with a 0x80004005 or "module not found," that DLL is your problem — run sfc /scannow to repair it before re-registering.

For Office-specific 0x800401E5 (usually when launching Word or Excel with a specific doc), the fix is often a repair install. Go to Settings > Apps > Installed apps, find Microsoft 365 or Office, click the three dots, choose Modify > Quick Repair. If that doesn't clear it, run Online Repair. I've watched that solve this exact error maybe 40 times.

Cause 3: User profile corruption or missing COM+ registration

Rarer, but it happens. Something in your user hive — HKCU\Software\Classes — got mangled, or the COM+ catalog itself is damaged. You'll know it's this one because the error follows you across every app, and re-registering DLLs as an admin doesn't help. It's per-user.

A common trigger: you synced your profile with a domain controller or OneDrive Known Folder Move, and the merge clobbered some class registrations. Or a restore from an old backup brought back stale keys.

Fix: create a new user profile to confirm, then repair

1. Create a fresh local account: Settings > Accounts > Other users > Add account.
2. Sign into it. Try opening the file that was throwing 0x800401E5.
3. If it works on the new account, your old profile is the problem — migrate your data over and delete the old one. It's faster than trying to surgically repair a hive.
4. If it still fails on a fresh profile, rebuild the COM+ catalog from an elevated prompt:

cd %windir%\system32
regsvr32 /s comcat.dll
msdtc -uninstall
msdtc -install

Reboot after. The Distributed Transaction Coordinator rebuild won't fix everything, but it resets the catalog enough that most moniker resolution errors clear.

Quick-reference summary

If none of that clears it, check Event Viewer under Windows Logs > Application right after the error fires. The DCOM 10016 and DistributedCOM entries nearby usually name the exact CLSID that's failing to resolve. Feed that CLSID into reg query HKLM\SOFTWARE\Classes\CLSID /s and you'll find what's supposed to own it. That's your last mile.