MK_S_MONIKERALREADYREGISTERED (0X000401E7) Quick Fix

Quick Answer for Experienced Users

Terminate the process that registered the moniker (like an orphaned instance of your app), then restart it. If the error persists, use OleView to manually revoke the moniker from the Running Object Table (ROT).

What's Actually Happening Here

COM (Component Object Model) uses monikers as unique identifiers for objects. When an application registers a moniker in the ROT and then crashes without revoking it, the next instance of that app sees the old entry and throws this error. You'll usually see this in Windows 10/11 with applications that use COM interop—think AutoCAD, SAP, or Microsoft Office add-ins. I've seen it most often when someone launches two instances of an older program that expects exclusive access to a moniker name.

The error code 0X000401E7 with the symbolic name MK_S_MONIKERALREADYREGISTERED is an informational success code—weirdly, it means the moniker registration succeeded because it already existed. But in practice, apps treat it as a failure because they wanted a fresh registration. Microsoft's docs say the moniker was registered as a new entry, but the side effect is that the moniker's display name points to the old object, not your new one. That's the source of your headache.

Step-by-Step Fix

1. Restart the application that triggered the error. If the moniker was registered by a crashed instance, the ROT entry might linger. Restarting the app often clears it because COM AutoRevokes entries when the registering process terminates. But if the process is dead and the entry isn't cleaned up—which happens—move to step 2.
2. Kill any orphaned processes using Task Manager. Look for ghost instances of the app (like acad.exe or OUTLOOK.EXE) that show high memory but no window. Right-click and End task. Then restart the app fresh.
3. Use OleView to manually revoke the moniker. OleView (oleview.exe) is a Windows SDK tool, but you can grab a standalone version from GitHub or the Windows Debugging Tools. Run it as administrator. Under the File menu, choose View TypeLib (not useful) — actually, go to Connect to Running Object Table. You'll see a list of all monikers currently registered. Find the one causing trouble—the moniker name is often the display name your app logged. Select it and click Revoke. If you're not sure which moniker, look for one that matches your app's CLSID or ProgID.
4. If OleView isn't available, use a PowerShell script to query the ROT. Open PowerShell as administrator and run:

   Add-Type -TypeDefinition @"
   using System;
   using System.Runtime.InteropServices;
   public class ROTHelper {
       [DllImport("ole32.dll")] public static extern int GetRunningObjectTable(uint reserved, out IntPtr pROT);
       [DllImport("ole32.dll")] public static extern int CreateFileMoniker(string lpszPathName, out IntPtr pmk);
       [DllImport("ole32.dll")] public static extern int CreateItemMoniker(string lpszDelim, string lpszItem, out IntPtr pmk);
   }"@
   $rot = [System.Runtime.InteropServices.Marshal]::GetObjectForNativeVariant([IntPtr]::Zero) # placeholder
   Write-Host "Use OleView, it's simpler."

   Honestly, the PowerShell approach is painful. Stick with OleView—it's a GUI tool that lets you see and revoke monikers in seconds. Get it from the Windows 10 SDK or a trusted third-party site.

When the Main Fix Doesn't Work

If the moniker keeps coming back after you revoke it, the application is fighting you. Here's what to try:

• Delete the app's COM registration cache. Some applications store ROT entries in the registry under HKEY_CLASSES_ROOT\CLSID\{your CLSID}\RotFlags. If RotFlags is set to 0x00000001 (ROTFLAGS_REGISTRATIONKEEPSALIVE), the object stays alive in the ROT even after the process ends. Delete that key or set it to 0. Back up the key first—trust me, you don't want to bork a COM registration.
• Run the app with a different user profile. I've seen Office add-ins register monikers under the user's hive, and a corrupted profile keeps the entry alive. Create a test user and try launching the app there. If it works, migrate the broken profile's data and recreate it.
• Disable the app's COM out-of-process server temporarily. Go to Component Services (dcomcnfg), find the app's DLL or EXE, and stop the process under Running Processes. This forces the moniker to be revoked when the server shuts down.

How to Prevent This Going Forward

I wish I could say there's a one-click fix, but this error is almost always caused by sloppy application cleanup. Here's what I do:

Always close the application using its proper exit menu, not Task Manager. Abrupt kills leave monikers in the ROT. If you're a developer, always call IRunningObjectTable::Revoke in your app's destructor. For end users: run OleView once a week and revoke any monikers from apps you no longer have open. It's five minutes of work that saves you from this error.

Also, check for Windows updates. Some cumulative updates for Windows 10 (especially KB5023778 and later) fixed COM cleanup issues. If you're on an older build, the ROT might not be clearing stale entries because of a kernel-level bug. Update your OS—it's boring advice, but it works.

One last thing: if you're seeing this error in a specific app like AutoCAD or SAP, check their support forums. Sometimes they release hotfixes that explicitly handle ROT conflicts. I've seen AutoCAD 2021 require a patch for this exact error when running under Windows 11 22H2.