COMADMIN_E_COMPFILE_LOADDLLFAIL 0X80110425: Quick Fix

The fix that works 9 times out of 10

I've seen this error pop up on everything from Windows Server 2012 R2 to Server 2022, and even on some stubborn Windows 10 workstations running old COM+ apps. Here's the deal: when you get 0X80110425, the COM+ subsystem is basically saying "I found the DLL file, but I can't load it." That usually means one of two things: a missing dependency (like a Visual C++ runtime) or a bitness mismatch between the COM+ app and the DLL.

Let's fix it. Open Component Services (type dcomcnfg in Run), then navigate to Component Services > Computers > My Computer > COM+ Applications. Find the app that's throwing the error — it'll usually have a red X or won't start. Right-click it and go to Properties, then the Components tab. Look at the DLL listed under your component. Write down its full path.

Now, here's the critical check: go to that DLL file in File Explorer, right-click, select Properties, then the Details tab. Look for "File description" and note if it says "32-bit" or "64-bit." Then go back to the COM+ app properties, Activation tab, and check if it's set to Server application or Library application. If it's a Server app and the DLL is 64-bit, you're good. But if the DLL is 32-bit and the COM+ app is set to run as a 64-bit server application, you've found your problem. Switch the COM+ app to Library application instead — this forces it to run inside the host process's bitness. Restart the app, and 90% of the time, that's it.

Why this works

COM+ has a nasty habit of running server applications as separate 64-bit processes by default on 64-bit Windows. But old 32-bit DLLs can't load into a 64-bit process — it's like trying to plug a USB-A into a USB-C port without an adapter. Setting the app to Library application makes it run inside the calling process (like a 32-bit IIS worker process or a 32-bit admin tool), which matches the DLL's bitness. Had a client last month whose entire print queue died because of this — the COM+ app for their label printer had a 32-bit DLL but was set to run as a 64-bit server. Took me longer to explain than to fix.

If that doesn't work: missing VC++ runtime

Still stuck? Check the DLL's dependencies. Download Dependency Walker (or use dumpbin /dependents yourfile.dll in a command prompt). You'll often see dependencies on msvcr120.dll or msvcr140.dll — those are Visual C++ 2013 and 2015-2022 runtimes. Install the appropriate Visual C++ Redistributable for your system's architecture (x86 or x64). Don't just grab the x64 one — if the DLL is 32-bit, you need the x86 redistributable. I keep a USB stick with all the major VC++ versions from 2005 through 2022 for exactly this reason.

Less common variations

Sometimes the DLL is legitimately corrupted or missing. Run sfc /scannow from an admin command prompt to check system files. If the DLL is part of a third-party COM+ application, reinstall that app — but first, check the event logs under Applications and Services Logs > Microsoft > Windows > COM+. The error details there might say exactly which DLL failed and why (like "The specified module could not be found").

Another variation: permissions. The COM+ application runs under a specific identity (often NetworkService or a custom account). That account needs Read & Execute permissions on the DLL file itself and on its containing folder. Right-click the DLL's parent folder, go to Security, and add the COM+ app's identity with those permissions. I've seen this happen on corporate image deployments where security policies strip inherited permissions.

Last weird case: Antivirus. Some aggressive endpoint protection (looking at you, Symantec Endpoint Protection) will block DLL loading for COM+ apps it doesn't recognize. Temporarily disable the real-time protection, restart the COM+ app, and if it works, add an exclusion for that DLL's path.

Prevention

• Document the bitness of every COM+ DLL you deploy. Keep a simple text file or an Excel sheet with the DLL name, path, bitness, and its required VC++ runtimes.
• Test after Windows Updates. I've seen cumulative updates silently change VC++ runtime behavior. Re-run the COM+ app's installer after major updates to ensure dependencies are intact.
• Use a dedicated COM+ application identity instead of NetworkService. Create a local service account with minimal permissions, and apply it to all your COM+ apps. Makes permission issues easier to track.
• Keep a baseline with regsvr32 — after registering a COM+ DLL, run regsvr32 /u yourdll.dll before uninstalling, then regsvr32 yourdll.dll after reinstalling. This prevents orphaned registry entries that cause loading failures.