CO_E_ISOLEVELMISMATCH (0X8004E02F) — Fix in 2 Steps

Quick Answer

Set the 32-bit DLL to run under a 64-bit surrogate process by adding a DllSurrogate registry value under HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{your-clsid}.

I know this error is infuriating — it usually shows up when you're trying to get some old 32-bit COM DLL to work with a modern 64-bit app, or the other way around. You'll see it in event logs, or as a popup in your app. The root cause is simple: COM can't match the bitness of the caller and the callee.

Why This Happens

COM objects are compiled as either 32-bit or 64-bit. When a 32-bit app tries to instantiate a COM object that's registered as 64-bit, COM raises CO_E_ISOLEVELMISMATCH. This tripped me up the first time too, back when I was supporting a legacy accounting plugin on Windows 10. The object was registered in the 64-bit hive, but the app ran 32-bit.

The fix has two paths: compile your app to match the COM object's bitness, or tell COM to host the mismatched DLL in a surrogate process (DllHost.exe) of the correct bitness. The surrogate approach is usually faster and avoids recompilation.

Fix Steps

1. Find the CLSID of the COM object
   Open Registry Editor (regedit.exe). Hit Ctrl+F and search for your COM object's name, or look in HKEY_CLASSES_ROOT\CLSID for 64-bit objects, and HKEY_CLASSES_ROOT\Wow6432Node\CLSID for 32-bit ones. Note the CLSID GUID (e.g., {12345678-1234-1234-1234-123456789abc}).
2. Check the current bitness
   Under the CLSID key, look for InprocServer32. The (Default) value will show the DLL path. If it's in C:\Windows\System32, it's 64-bit. If it's in C:\Windows\SysWOW64, it's 32-bit.
3. Add a DllSurrogate value
   If your app is 32-bit and the COM object is 64-bit (or vice versa), go to the CLSID key in the other bitness's registry hive. For example, if the 64-bit object is registered under HKEY_CLASSES_ROOT\CLSID\{GUID}, create a new String value named DllSurrogate under that same key. Set its value to an empty string (just double-click and hit OK). This tells COM to launch a 64-bit surrogate process for the DLL.

Important: If you get an access denied error editing the registry, you need to take ownership of the key first — right-click it, go to Permissions, then Advanced, and change the owner to Administrators. Then grant yourself Full Control.

Test the Fix

Restart your app. If the error still appears, check the Event Viewer under Windows Logs > Application for entries from COM with ID 10001. That will tell you exactly which CLSID failed and whether the surrogate spawned.

Alternative Fix: Rebuild the App for Matching Bitness

If you control the source code, recompile your app to match the COM object's bitness. For a C# app, change the project target to x64 or x86 in Visual Studio (Project Properties > Build > Platform target). For C++, set the architecture in the solution configuration. This avoids the surrogate entirely but might break other dependencies.

Alternative Fix: Register the COM Object Under Both Hives

Some COM objects can work under either bitness if they're installed properly. Uninstall your current version, then run the installer with admin rights. Many installers register the DLL in both hives automatically. If yours doesn't, you can manually register it using regsvr32.exe from the correct bitness folder: run C:\Windows\SysWOW64\regsvr32.exe yourdll.dll for 32-bit, or C:\Windows\System32\regsvr32.exe yourdll.dll for 64-bit.

Prevention Tip

When building COM components, stick to one bitness for your entire stack — all 64-bit if your system supports it. Keep a compatibility test that runs both 32-bit and 64-bit test apps against your COM object. I also recommend adding a check in your installer script that warns the user when they're mixing architectures. For example, an Inno Setup [Code] section that inspects the system bitness and adjusts registration paths. Saves headaches later.