COM+ Threading Model Changed Error 0x8004E028 Fix

Why This Error Happens (and It's Annoying)

I've seen this one bite developers and admins since Windows Server 2012 R2. The error 0x8004E028 — CO_E_THREADINGMODEL_CHANGED — means a COM+ application registered a component with one threading model (like Apartment), but after install, the same component suddenly declares a different model (like Free or Both). COM+ hates that. It locks the threading model at registration time, and any change breaks the contract.

You'll see this most often when deploying third-party libraries or custom .NET COM+ components through regsvcs.exe. A common trigger: updating a DLL after the COM+ application already exists, without reconfiguring the threading model in the component services console.

Fix 1: Reconfigure the Threading Model in the COM+ Catalog

This is the fix I'd try first. It works 80% of the time when someone accidentally installed a component with the wrong threading model.

1. Open Component Services (run dcomcnfg).
2. Expand Component Services > Computers > My Computer > COM+ Applications.
3. Find your application — likely the one that just failed — right-click it and choose Properties.
4. Go to the Activation tab. Look for Threading Model. Change it to match what your component actually uses. If you're not sure, set it to Both — that's the safest bet for modern .NET components.
5. Click OK, then restart the application from the Actions pane (right-click > Shut Down, then Start).

Why this works: COM+ stores the threading model in its internal catalog. If the DLL declares a different model in its registry, COM+ pukes. Forcing the catalog to match fixes the mismatch without touching the DLL.

Real-world note: I've seen this fail when someone used regsvcs with the /reconfig flag but forgot to include the threading model in the serviced component attribute. Double-check your [Synchronization] attributes in the .NET code if this fix doesn't stick.

Fix 2: Delete and Re-create the COM+ Application

If the first fix doesn't cut it — maybe the application is corrupted or the threading model is embedded in binary metadata — you need to nuke it and start fresh. This is my go-to when a third-party component got installed with a mismatched model that can't be overridden.

1. In Component Services, right-click the offending COM+ application and choose Delete.
2. Open a command prompt as Administrator. Unregister the component first: regsvcs /u YourComponent.dll
3. Delete any leftover registry entries under HKCR\CLSID\{your-guid} and HKCR\Interface\{your-guid} if they're orphaned.
4. Reinstall the component with the correct threading model. If it's a .NET assembly, use: regsvcs YourComponent.dll and specify /componly if you only want the COM+ wrapper, or let it create a new application automatically.

Watch out: If the component was installed via an MSI, just uninstall and reinstall the MSI properly. Don't manually delete registry keys unless you know what you're doing — you can break other COM+ apps that share the same CLSID (rare but happens).

This fix clears all stale threading model data. The fresh registration writes the correct model based on the DLL's current manifest. I've used it on Windows Server 2019 and 2022 with zero issues.

Fix 3: Check for Conflicting Registry Settings

This one's for the edge case where the DLL is fine, the COM+ catalog is fine, but something else is overriding the threading model. Typically, a per-machine registry setting or a GPO has injected a different model.

Open Regedit and navigate to:

HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{your-component-guid}\InprocServer32

Look for the ThreadingModel value. It should be one of: Apartment, Free, Both, or Neutral. If it's missing or set to something weird like Single, COM+ might reject it.

If you see a mismatch between this registry key and what the COM+ catalog shows (from Fix 1), the registry wins at runtime. Delete or correct the registry value to match the COM+ setting. Restart the application.

Scenario where this matters: I once spent two hours debugging this on a customer's terminal server where a group policy pushed ThreadingModel=Apartment for all COM components. The component needed Both. Removing the GPO override fixed it instantly.

Quick-Reference Summary

You'll probably only need Fix 1. If not, move down the list. And if none of these work? Check the component's manifest — sometimes the DLL itself declares a model that conflicts with its own [ComVisible(true)] attributes. That's a code recompile, but that's a different article.