Fix 0x80040110 Class E No Aggregation Error

Yeah, This Error Is Annoying. Let's Fix It.

The 0x80040110 error (CLASS_E_NOAGGREGATION) pops up when a COM class doesn't allow aggregation — basically, something tried to wrap it like a gift, and the gift box said "nope." I've seen this mostly with legacy software, custom COM components, or after a bad Windows update. Don't waste time hunting for phantom fixes. Here's what actually works.

The Quick Fix: Re-register the Problem DLL

Nine times out of ten, a corrupted or missing registration for the COM class triggers this. Open an elevated Command Prompt (right-click, Run as Administrator) and run:

regsvr32.exe /u [path to the DLL]
regsvr32.exe [path to the DLL]

Replace [path to the DLL] with the actual file — e.g., C:\Program Files\SomeApp\someclass.dll. If you don't know which DLL, check the error details in Event Viewer under Windows Logs > Application. Look for the CLSID. Then search the registry under HKEY_CLASSES_ROOT\CLSID\{your-clsid} for the InprocServer32 value — that's your DLL path.

Had a client last month whose entire print spooler crashed because of a misregistered printer driver DLL. Ten seconds of regsvr32 fixed it.

Why This Works

COM aggregation is when one object "borrows" another object's interface, like a wrapper. The error means the class explicitly says "I don't do that." Re-registering the DLL resets the COM metadata — it rewrites the InprocServer32 entry and the threading model. Often the registry gets corrupted after an update or a bad uninstall, making the COM runtime misinterpret the class's aggregation flags. A clean registration fixes the mismatch.

Less Common Variations

If regsvr32 doesn't help, check these:

Remote COM object: The error text can also say "or class object is remote." If the class is supposed to live on another machine (e.g., DCOM), verify the machine name and permissions in dcomcnfg (Component Services). Right-click My Computer, go to Properties > COM Security, and ensure the launching user has access.
64-bit vs 32-bit mismatch: If you're running a 32-bit app on a 64-bit system, the DLL might be in C:\Windows\SysWOW64 instead of System32. Register the 32-bit version using the 32-bit regsvr32 from C:\Windows\SysWOW64\regsvr32.exe.
Permission issues: The user account running the app might lack permissions to the COM class. Check the registry key's security — add NETWORK SERVICE or INTERACTIVE with Read/Execute rights if needed.
Corrupted COM+ catalog: In extreme cases, the COM+ catalog itself gets hosed. Reset it via regsvr32.exe /u comsvcs.dll then regsvr32.exe comsvcs.dll — but back up first.

Prevention for Next Time

Before major updates: Create a system restore point. Updates sometimes deregister COM classes.
Use proper uninstallers: Don't delete DLLs manually. Always use the app's uninstaller or regsvr32 /u.
Keep DLLs in their original paths: Moving a COM DLL breaks its registration. If you move it, re-register it.
Test aggregation: If you're writing your own COM classes, check the CoCreateInstance flags — CLSCTX_INPROC_SERVER vs CLSCTX_LOCAL_SERVER. Use the right one.

That's it. No fluff, no rabbit holes. Regsvr32 fixes 90% of these. If it doesn't, check remote configs or architecture mismatches. You'll be back up in five minutes.