COM+ Service App Pool/Recycle Error 0X8011080D Fix

Quick Answer

You can't pool or recycle a COM+ application that runs as a Windows NT service. The only fix is to reconfigure the application to run as a server application instead of a service, or accept the limitation and adjust your management scripts accordingly.

Why This Happens

This error trips up admins who've been managing COM+ apps for years. It's not a bug—it's a deliberate design choice. When a COM+ application is configured to run as an NT service, Windows treats it like any other system service. Services have a single instance lifetime tied to the Service Control Manager (SCM). Pooling and recycling require the ability to spin up multiple worker processes, kill them gracefully, and respawn them—all things the SCM doesn't support for services. You'll hit this error most often when using PowerShell scripts or the Component Services MMC snap-in to set the Poolable or RecycleLifetime properties on a service-configured app. I've seen it on Windows Server 2016 and 2019 mainly, but it affects all supported versions.

Fix Steps

1. Open Component Services — Run dcomcnfg or go to Administrative Tools > Component Services. Expand Component Services > Computers > My Computer > COM+ Applications.
2. Identify the problem app — Right-click the application throwing the error, select Properties.
3. Check the Activation tab — Under Activation type, if Run application as NT Service is selected, that's your culprit.
4. Change activation type — Switch to Server application. This makes the COM+ app run as a dedicated process (dllhost.exe) that supports pooling and recycling.
5. Important: If the app requires running under a specific user account or needs to interact with the desktop, you'll need to configure the identity on the Identity tab. Choose a domain account with appropriate privileges.
6. Apply and restart — Click OK, then right-click the application and choose Shut down. Then right-click again and select Start.
7. Verify — Open a PowerShell prompt as admin and run Get-WmiObject -Namespace root\CIMV2 -Class Win32_COMApplication | Where-Object { $_.Name -eq "YourAppName" }. Check the RunAsService property is now False.

Alternative Fixes

If you can't change the activation type (maybe a vendor locked it down or it breaks the app), you have two options:

• Stop trying to recycle — Write your monitoring scripts to ignore this specific app. Use Event IDs to filter out the error. It's ugly but quick.
• Use service restart instead — Stop the COM+ service manually via sc stop COMSysApp and then restart it. This kills all COM+ service-hosted apps, so it's a sledgehammer approach. Test in dev first.

Skip the registry hacks or permission changes—they won't fix the fundamental architectural limitation.

Prevention Tip

Before you configure a new COM+ app, decide upfront: does it need pooling or recycling? If yes, never set it to run as an NT service. Use server application mode and assign a dedicated identity. That way you avoid the headache later. Document this in your deployment runbook—it'll save your night shift team from a frantic call at 3 AM.