OLE_E_CANT_GETMONIKER (0x80040009): Fix It in 30 Seconds to 15 Minutes

I know this one's infuriating. You double-click a shortcut, launch an old app, or run a script, and Windows throws OLE_E_CANT_GETMONIKER (0x80040009) — sometimes with the friendly addendum "Not able to get the moniker of the object." It reads like gibberish, and Microsoft's own docs describe it in a way that helps nobody.

Here's the plain English version: a moniker is COM's word for a reference — a pointer to where an object lives. When Windows can't resolve that reference, you get 0x80040009. Nine times out of ten, the target moved, got deleted, or a registry entry is pointing at a ghost. Let's walk through this from fastest to deepest. Stop whenever it works.

Fix 1 (30 seconds): Check the shortcut target

If this error shows up when you double-click a shortcut, the shortcut is almost certainly the culprit. The .lnk file stores a moniker to whatever it launches, and if that target is gone, Windows can't resolve it.

1. Right-click the shortcut → Properties.
2. Look at the Target field. Does that path actually exist?
3. If not, click Find Target or browse to the correct .exe manually.
4. Hit Apply, then try launching again.

Real-world trigger I've seen a dozen times: someone installs Office 2016, uninstalls it, then installs Microsoft 365. Old pinned shortcuts on the Start menu still point at C:\Program Files\Microsoft Office\root\Office16\WINWORD.EXE from the previous install. The path changed. The moniker didn't. Rebuild the shortcut and 0x80040009 disappears.

While you're in there, check the Start in field too. If it references a folder that no longer exists, some apps will throw the same error even when the executable is fine.

Fix 2 (5 minutes): Rebuild or delete the broken moniker

If the shortcut looks fine but still fails, or if the error comes from a script or scheduled task, the stored moniker itself is corrupt. Windows keeps these in a few places, and stale ones cause chaos.

Delete and rebuild the .lnk

Don't edit it. Delete the shortcut entirely and create a new one from scratch. Right-click the real .exe → Send to → Desktop (create shortcut). Rebuilding forces Windows to write a fresh moniker, and that alone fixes a surprising number of cases.

Clear the Recent Items and jump list cache

Recent-documents entries are monikers too. If the error fires when you click a file in the jump list or the Recent Items folder, clear them:

del /f /q "%APPDATA%\Microsoft\Windows\Recent\*"

Then restart Explorer from Task Manager (Windows Explorer → Restart) so the shell rebuilds its lists.

Check scheduled tasks and COM registrations

If the error appears from a scheduled task or a COM client (Excel VBA, an old VB6 app, a Citrix/RemoteApp launcher), the reference isn't a shortcut — it's a registry entry. Open regedit and search for the CLSID that's failing. You'll usually find it under:

HKEY_CLASSES_ROOT\CLSID\{GUID}\LocalServer32

If the path in LocalServer32 points at a file that doesn't exist, that's your moniker problem. Repoint it to the correct executable, or re-register the DLL:

regsvr32 "C:\path\to\your.dll"

Fix 3 (15+ minutes): The deep fixes for stubborn cases

When the shortcut is clean and the COM path is right but 0x80040009 still haunts you, it's time to go deeper. In my experience, the remaining causes fall into three buckets.

Bucket 1: DCOM identity and permissions

COM objects can run under a specific user identity. If that account was deleted, had its password changed, or lost "Log on as a batch job" rights, the moniker can't resolve at launch. Open dcomcnfg → Component Services → Computers → My Computer → DCOM Config. Find the app throwing the error, right-click → Properties → Identity tab. Set it to The interactive user or This user with current credentials. Reboot and retest.

Bucket 2: Corrupt user profile

I've seen this error follow a user around across every shortcut on their desktop — and disappear entirely on a fresh profile. That's a profile corruption signal. Test it fast: create a new local user, log in, and try the same shortcut. If it works, your old NTUSER.DAT is the problem. Migrate the data and move on. Seriously, don't try to repair a sick profile — it never ends well.

Bucket 3: Missing Visual C++ or .NET runtime

Some COM servers are actually managed .NET assemblies or C++ binaries that depend on specific redistributables. If the runtime is missing or a version mismatch exists, the object can't be created, and the moniker lookup fails. Install the matching Microsoft Visual C++ Redistributable (both x86 and x64 — install both, don't guess) and the .NET runtime version the app expects. Then re-register the component and retry.

Quick reference: which fix for which symptom

What won't help (so skip it)

SFC and DISM get recommended for every Windows error under the sun. For 0x80040009, they almost never fix it — this isn't a system-file corruption issue, it's a broken reference. Running sfc /scannow takes 10 minutes and gives you a clean bill of health for a problem that's elsewhere. Save yourself the time.

Also skip "repair install" of Windows unless you've exhausted everything above. It's a sledgehammer for what's usually a nail.

If the error only appears under a service account or scheduled task but works fine when you run it manually, that's a dead giveaway for the DCOM identity issue in Fix 3. Check that first before anything else.

Work through these in order and you'll have it sorted. If you hit a case where none of the three fixes land, the moniker in question is being created dynamically by an app — check that app's own event log entries in Event Viewer under Windows Logs → Application. The source column will usually name the component that's failing, and that's your real lead.