0X8011080F

Fix COMADMIN_E_CANTRECYCLELIBRARYAPPS (0X8011080F) Error

Windows Errors Intermediate 👁 0 views 📅 Jun 12, 2026

This error pops up when you try to recycle a COM+ library application. The fix: stop and restart the hosting process manually — don't bother trying to recycle it directly.

Quick answer

Stop and restart the process hosting the library app — usually dllhost.exe or a specific process under Component Services. You can't recycle a library app directly.

Why this happens

COM+ library applications run inside the process of the client that calls them. There's no dedicated host process to recycle. The error 0X8011080F (COMADMIN_E_CANTRECYCLELIBRARYAPPS) is Windows telling you exactly that — you're trying to recycle something that doesn't have its own process lifecycle. This trips up a lot of admins, especially after moving from server-app-style COM+ components where recycling works fine.

The culprit here is almost always someone clicking "Recycle" in the Component Services MMC snap-in on a library application. It'll throw this error every time. Real-world scenario: you've got a legacy VB6 or .NET COM+ component hosting shared business logic. You're patching the server and want to recycle the app to clear cached data — but you hit this error.

Fix steps

  1. Open Component Services — Press Win + R, type comexp.msc, hit Enter. Navigate to Component Services > Computers > My Computer > COM+ Applications.
  2. Find your library application — Look for the app that's marked as "Library Application" in its Properties > Activation tab. The error message might hint at the app name.
  3. Identify the hosting process — Right-click the library application, choose Properties > Advanced. Note the Process Identity — it'll be the identity used by the client process. Common hosts: IIS worker processes (w3wp.exe) or custom apps.
  4. Stop the client process — If it's IIS, recycle the app pool in IIS Manager. If it's a custom app, use Task Manager to kill the specific dllhost.exe or your app.exe. Do not kill all dllhost.exe instances — you'll nuke system stuff.
  5. Restart the client process — Start the app pool or launch the custom app again. The library app will load fresh when the client calls it.
  6. Verify — Back in Component Services, refresh the view. The library app should show as running. Test with a simple call.

Alternative fixes if the main one fails

  • Stop the COM+ system application — This is nuclear, but sometimes the library app is stuck due to a hung COM+ infrastructure. Run this in an admin PowerShell: Stop-Service COMSysApp. Then start it back up: Start-Service COMSysApp. This resets the COM+ catalog caching.
  • Convert to a server application — If you absolutely need to recycle it programmatically, change the app's activation type to Server Application in Properties > Activation. Drawback: it runs in its own dllhost.exe, which uses more memory and might break code that relies on in-process calls. Test this in a dev environment first.
  • Use a script to recycle the hosting process — If it's a known process ID, you can script it: Get-Process -Name "yourclientapp" | Stop-Process then restart it. Wrap this in a scheduled task if needed.

Prevention tip

Don't use library applications unless your component absolutely must run in-process with the caller (for performance reasons). Everything else should be a server application — it's easier to manage, easier to recycle, and won't throw this error. If you're stuck with library apps, automate the host process restart as a maintenance task. Also, set your COM+ application's pooling timeout low — under Properties > Pooling, set Pool Size to 0 and Recycle Time to something like 5 minutes. This forces fresh instances more often, reducing the need for manual recycling.

One last thing: if you're running this on Windows Server 2016 or older, the error might also appear due to a corrupt COM+ catalog. Run regsvr32 comadmin.dll and regsvr32 comcat.dll from an admin prompt, then reboot. But on Server 2019+, that's rarely needed.

Was this solution helpful?