COMADMIN_E_CAN_NOT_EXPORT_SYS_APP (0X8011044C) — Can't export System Application

You're in Component Services, right-click a COM+ application, choose Export, and boom — the error hits. The exact message reads COMADMIN_E_CAN_NOT_EXPORT_SYS_APP (0X8011044C) with text like "System application is not exportable." You see this most often on Windows Server 2019 or 2022, but it can happen on Windows 10/11 Pro too.

The trigger is simple: you're trying to export one of the built-in COM+ System Applications — things like COM+ Utilities, COM+ QC Dead Letter Queue Listener, or System Application itself. These aren't user-created apps. Microsoft built them into the OS to handle core COM+ plumbing. You can't export them the normal way because they're part of the system, not something you wrote.

Root cause — why this happens

The COM+ catalog marks system applications with a flag: APPFLAG_SYSTEM. When you right-click and choose Export, the Export Wizard calls the ExportApplication method, which checks that flag. If it's set, the method throws COMADMIN_E_CAN_NOT_EXPORT_SYS_APP immediately. No workaround in the GUI — the button's there, but it's a dead end for system apps.

There's no registry tweak or permission hack that removes that flag. The COM+ catalog is locked down hard. If you need the same components on another machine, you have to recreate the application manually or copy the underlying DLLs and register them. That's not elegant, but it's the only supported path.

The fix — step by step

1. Open Component Services. Press Win + R, type dcomcnfg, hit Enter. Expand Component Services > Computers > My Computer > COM+ Applications.
2. Identify the application. Look for apps with names like System Application, COM+ Utilities, or COM+ QC Dead Letter Queue Listener. Right-click the one you tried to export — you'll see the Export option is grayed out or gives the error.
3. Check the application's components. Double-click the system app to expand it, then click Components. In the right pane, you'll see one or more COM+ components listed. Each one points to a DLL file — note the DLL path in the Properties of each component.
4. Open an elevated Command Prompt. Click Start, type cmd, right-click Command Prompt, choose Run as administrator. Confirm the UAC prompt.
5. Export the component registrations manually using regsvr32. For each DLL you noted in step 3, run this command:

   regsvr32 /i /n "C:\full\path\to\component.dll"

   The /i flag calls DllInstall, which often registers the COM+ interface. The /n flag tells regsvr32 not to call DllRegisterServer (since COM+ components use a different registration method).
6. Copy the DLLs to the target machine. Put the same DLLs in the same folder path on the destination server. Then run the same regsvr32 commands there. This recreates the COM+ registration on the new box.
7. Reboot both machines — or at least restart the COM+ System Application service. On the target, open a Command Prompt as admin and run:

   net stop COMSysApp && net start COMSysApp

8. Verify. Back in Component Services on the target, refresh the view. You should see the system app now has its components listed. Right-click and try Export again — it'll still fail if you click the system app itself, but your custom components are present and working.

What to check if it still fails

If the components don't show up on the target, check these things:

• File paths must match exactly. If you put the DLL in C:\Program Files\MyApp\component.dll on the source, it has to be in exactly the same path on the target. COM+ stores absolute paths.
• Permissions. The account running the COM+ System Application service (usually NT AUTHORITY\NETWORK SERVICE) needs read/execute access to the DLL folder. Use icacls to check:

  icacls "C:\path\to\dlls"

• DLL dependencies. Run dumpbin /dependents component.dll from a Visual Studio Developer Command Prompt. If any dependencies are missing on the target, the registration will fail silently. Install the required VC++ redistributable or other runtimes.
• Event logs. Open Event Viewer, go to Windows Logs > Application. Filter for source COM+ or COM. You'll often see error IDs like 4135 or 4199 with details about why the component failed to load.

One more thing — if you're dead set on having the exact same system app on two machines, consider using Windows Server Migration Tools or System Center to clone the entire COM+ catalog. That's a bigger project, but for large environments it's the right way. For most people, just manually registering the DLLs is way faster and avoids the export error entirely.