Fix MK_S_US (0X000401E6) – Both Monikers Share a Common Prefix

Quick answer

Rename one of the conflicting objects so its moniker no longer shares a common prefix with the other, or clear the Running Object Table (ROT) with a tool like OLEView.exe.

What’s actually happening here

This error shows up in applications that use OLE (Object Linking and Embedding) or COM monikers—usually in older Windows software, CAD tools, or custom enterprise apps that embed OLE objects into documents. The error code MK_S_US (0X000401E6) is a success code with a warning: the system resolved the moniker, but the result was based on a non-unique prefix match.

Internally, a moniker is a name that identifies a COM object. When you have two registered monikers that start with the same string—say MyApp:Document1 and MyApp:Document10—and you try to resolve a partial match like MyApp:Document1, the system can’t tell which one you meant. It picks the first match it finds, and returns MK_S_US to warn you the match was ambiguous. This usually happens when the Running Object Table (ROT) has stale or overlapping entries.

The real-world trigger: you’re working in an Excel workbook that links to embedded OLE objects from a legacy CAD program, and one of the linked objects was duplicated or renamed. Or you’re running a custom COM server that registers multiple instances with similar monikers.

How to fix it

1. Identify the conflicting monikers. Use OLEView.exe (part of the Windows SDK) or a tool like ROT Viewer. Open the Running Object Table tab. Look for entries that share a common prefix—e.g., MyApp:Obj1 and MyApp:Obj10. Those are your culprits.
2. Rename one object. If the objects are under your control (e.g., you created them in your own app), change the name of one so the prefix is different. For example, rename MyApp:Obj1 to MyApp:Obj01 or MyOtherApp:Obj1. The system matches by longest prefix, so unique prefixes resolve unambiguously.
3. Clear the stale ROT entry. If the objects are not currently in use, right-click the offending entry in OLEView.exe and select Revoke. This removes it from the ROT. On the next binding request, the system won’t see the duplicate.
4. Restart the COM server. Close and reopen the application that registered the monikers. Many OLE servers register entries only on startup; a fresh start clears old ones.
5. Use explicit moniker binding. In your code, if you control the binding logic, call MkParseDisplayName() with the full moniker string instead of a partial one. This bypasses prefix matching entirely.

If the main fix doesn’t work

Sometimes the conflict is in the system-wide ROT and persists across app restarts. Here’s what else to try:

• Reboot. Sounds basic, but the ROT lives in memory. A full reboot wipes it clean.
• Check for background OLE servers. Open Task Manager and kill any lingering instances of dllhost.exe or excel.exe that might hold old moniker registrations.
• Run a dedicated ROT cleanup script. PowerShell can enumerate and revoke entries using the rotview COM object (if available). I’ve written a quick script for this: $rot = New-Object -ComObject 'ROTView.RotViewer'; $rot.EnumEntries() | Where-Object { $_.Name -like 'MyApp:*' } | ForEach-Object { $rot.Revoke($_.Mk) }. Adjust the prefix filter to match your conflict.

How to prevent it from happening again

Name your monikers with unique, non-overlapping prefixes from the start. If you control the OLE server, append a GUID or a timestamp to each moniker—e.g., MyApp:{UUID} or MyApp:2025-03-15_14:30:00. This guarantees no two entries share the same prefix. Also, always revoke monikers when objects are destroyed. Call IRunningObjectTable::Revoke() in your cleanup code. Stale ROT entries are the number one cause of MK_S_US in production systems.

I’ve seen this error most often in custom OLE document servers where developers used sequential IDs without padding. Obj1 and Obj10 share the prefix Obj1, and the system always picks the wrong one. Pad your IDs: Obj001 and Obj010 solve it.