| Previous | Next |
| CONTEXT_E_NOTRANSACTION | CO_E_NOIISINTRINSICS |
CO_E_THREADINGMODEL_CHANGED
CO_E_THREADINGMODEL_CHANGED is the failure HRESULT 0x8004E028 (signed decimal -2147164120, unsigned decimal 2147803176). Its severity bit is 1, facility is 4 (FACILITY_ITF), and the facility-specific code field is 0xE028.
The deployed class no longer matches the threading model recorded by COM+
This HRESULT means the component’s threading model changed after it was installed in a COM+ application. COM+ built activation and context assumptions from the installed metadata, so replacing registration or binaries without reinstalling the component makes that configuration unsafe.
AllStat describes the result as “The components threading model has changed after install into a COM+ Application. Please re-install component.” for it, this wording identifies the immediate COM+ condition, while surrounding context and earlier events determine why it was reached.
Contract boundary
The comparison is between the threading model recorded when the component was installed and the model currently advertised by the class registration or build. It is not a runtime race inside the component.
Causes that fit this specific result
- An upgrade changes the
ThreadingModelregistration but skips COM+ component reinstallation. - A DLL with different apartment assumptions replaces the installed binary in place.
- 32-bit and 64-bit registrations expose inconsistent threading models for the same CLSID.
- Manual registry edits diverge from the COM+ catalog.
Evidence to preserve before changing the system
- Record CLSID, application ID, DLL path, file version, architecture, and current
ThreadingModelvalue. - Export the COM+ component configuration before repair.
- Compare the new build’s registration script with the previously installed package.
- Check both registry views when the application architecture changed.
Diagnostic sequence
- Stop treating binary replacement as a complete COM+ deployment.
- Remove and reinstall or reimport the component through supported Component Services operations.
- Validate apartment behavior and proxy/stub registration for the new threading model.
- Run concurrent activation tests after the catalog and registry agree.
Retry and recovery
Reinstall the component so COM+ records the new threading contract. Repeated activation without reinstalling will continue to fail and could not safely infer the new model.
What the result does not establish
The code does not mean a thread called CoInitializeEx incorrectly. It identifies deployment-time model drift for a configured component.
Difference from nearby HRESULT values
RPC_E_CHANGED_MODE concerns conflicting apartment initialization on a thread. CO_E_ACTIVATIONFAILED_CATALOGERROR is broader catalog or configuration failure.
Practical scenario
A vendor updates an Apartment-threaded component to Both-threaded and copies the DLL onto the server. The old COM+ catalog entry remains; activation returns this HRESULT until the component is reinstalled from the new package.
Developer and telemetry guidance
Package COM+ catalog changes and binaries as one deployment unit. Preflight checks should compare registered threading model, architecture, and file hash before application recycle.
Official Microsoft references
- Microsoft: COM transaction and context error codes
- Microsoft: configuring COM+ applications
- Microsoft: the COM+ catalog
- Microsoft: COM+ Components collection
- Microsoft: HRESULT values in MS-ERREF
Looking for a different code? Search another status or error code.