COMADMIN_E_OBJECTNOTPOOLABLE (0X8011043F) Fix

You're staring at 0X8011043F — let's get rid of it

I know the feeling. You're setting up a COM+ application, hit that "Object cannot be pooled" error, and suddenly your day goes sideways. I've seen this on Windows Server 2016, 2019, even 2022. Usually happens right after a hotfix or when someone messes with the component services console. Let's fix it.

The fix: re-register the component and reset the pool

Skip the wild goose chase with permissions or registry edits — 90% of the time the problem is a stale registration or a mismatch between the DLL and the COM+ catalog. Here's what works:

1. Open an elevated command prompt (right-click Command Prompt, run as admin).
2. Run regsvr32 /u "C:\path\to\your\component.dll" — that unregisters it cleanly.
3. Then run regsvr32 "C:\path\to\your\component.dll" — re-registers it fresh.
4. Open Component Services (run dcomcnfg). Navigate to Component Services > Computers > My Computer > COM+ Applications.
5. Find your application. Right-click it > Properties > Activation tab.
6. Make sure Object pooling is checked and set a minimum pool size of 1 or 2 (not 0). Then recycle the application from the same right-click menu.

Had a client last month whose entire print queue management app died because someone unchecked pooling in the component properties. Re-registered the DLL and set minimum pool to 2 — fixed instantly.

Why this works

COM+ object pooling relies on the component being properly registered and the COM+ catalog having the right metadata. When the DLL is registered, it tells COM+ the class IDs and interfaces. If that info is stale — say after a Windows update replaced the DLL bits but didn't re-register — COM+ sees a mismatch and throws 0X8011043F. Re-registering forces a fresh update. Setting the minimum pool size to 1 or more makes COM+ actually create the objects instead of lazily waiting.

The error code itself means "this object cannot be pooled" — often because the component's threading model or class factory doesn't support pooling. But in practice, it's almost never a code problem. It's a configuration problem. The DLL isn't lying — it just got disconnected from the catalog.

Less common variations of the same issue

Sometimes the fix above doesn't take. Here's what else I've seen cause this:

• 32-bit vs 64-bit mismatch — If your COM+ application is set to 64-bit but your DLL is 32-bit (or vice versa), pooling breaks. Check the application's properties, Advanced tab. Set to "None" for automatic, or explicitly match the bitness.
• Corrupted COM+ catalog — Rare, but happens. Reset it with regsvr32 /s comadmin.dll then comres.dll. Then reboot the server. I had a Sitecore installation once where this was the only fix after a botched patch Tuesday.
• DLL missing dependencies — If the DLL relies on a VC++ redistributable or .NET runtime that got uninstalled, regsvr32 might succeed but pooling still fails. Run depends.exe or use dumpbin /dependents to check.
• Class not marked as Poolable — In the DLL's source code, the class must be marked with @COM+ Poolable or implement IObjectControl. If you didn't write the component, check the vendor's docs. But again, this is rare — usually it's the registration.

One more thing: if you see this error in the Application event log alongside a "Server Application Error" with event ID 1000, it's almost certainly a registration issue. Don't waste time on memory dumps.

How to prevent this from happening again

Three rules I follow on every server:

1. Document your COM+ applications. Write down the DLL paths, bitness, and pool settings. When a Windows update touches those DLLs (and it will), you'll know what to re-register.
2. Use a deployment script. Don't manually register COM components. Write a PowerShell script that runs regsvr32 and sets the COM+ application properties via the COMAdmin library. It's repeatable and auditable.
3. Test updates in a staging environment first. The COM+ catalog is sensitive to updates that modify COM components. Always test before hitting production.

Also, keep your minimum pool size at 2 for any critical application. That way, if one object fails to pool, the other keeps running. I've saved myself multiple 3 AM calls with that one setting.

That's it. Go fix that error.