| Previous | Next |
| CO_E_NOSYNCHRONIZATION | CO_E_CALL_OUT_OF_TX_SCOPE_NOT_ALLOWED |
CO_E_ISOLEVELMISMATCH
CO_E_ISOLEVELMISMATCH is the failure HRESULT 0x8004E02F (signed decimal -2147164113, unsigned decimal 2147803183). Its severity bit is 1, facility is 4 (FACILITY_ITF), and the facility-specific code field is 0xE02F.
The child component cannot strengthen an isolation level already fixed by the root
This HRESULT means the component being created has a TxIsolationLevel stronger than the isolation level of the root component for the current transaction. COM+ cannot insert the child into that transaction while promising stronger semantics than the transaction already provides.
AllStat describes the result as “The TxIsolation Level property for the COM+ component being created is stronger than the TxIsolationLevel for the "root" component for the transaction. The creation failed.” for it, this wording identifies the immediate COM+ condition, while surrounding context and earlier events determine why it was reached.
Contract boundary
Isolation is determined at the transaction boundary. A nested participant cannot upgrade an existing root transaction by configuration alone; it must either accept the root level or start a separate transaction when the design permits.
Causes that fit this specific result
- A root component uses Read Committed while a called component requires Serializable.
- Configuration drift changes only the child isolation attribute.
- A shared component is reused under callers with different transaction roots.
- The design assumes each component independently negotiates isolation inside one automatic transaction.
Evidence to preserve before changing the system
- Record root and child CLSIDs, transaction ID, transaction attributes, and effective isolation levels.
- Capture the activation chain that chose the root transaction.
- Compare Component Services settings across environments.
- Document which data invariants actually require the stronger level.
Diagnostic sequence
- Map isolation requirements from the transaction root through every nested component.
- Lower the child requirement only after validating its concurrency assumptions.
- Raise the root isolation when the whole transaction needs stronger protection and capacity permits it.
- Use Requires New only when splitting atomicity is an intentional design decision.
Retry and recovery
Align isolation configuration before activating the child in that transaction. Repeating the same activation under the same root level will fail consistently.
What the result does not establish
The result does not report a database deadlock and does not prove the database supports every configured isolation mode. It is a COM+ configuration compatibility check.
Difference from nearby HRESULT values
XACT_E_ISOLATIONLEVEL concerns unsupported isolation at the transaction-manager interface. CONTEXT_E_NOTRANSACTION means no transaction exists at all.
Practical scenario
A reporting child is configured Serializable but is called inside a Read Committed order transaction. COM+ rejects creation; architects either align the child to the root or move reporting into a deliberate separate transaction.
Developer and telemetry guidance
Store transaction and isolation attributes as code-reviewed deployment data. Traces should identify the root component so operators do not change the child without understanding the full atomic boundary.
Official Microsoft references
- Microsoft: COM transaction and context error codes
- Microsoft: configuring COM+ transactions
- Microsoft: managing automatic COM+ transactions
- Microsoft: configuring COM+ applications
- Microsoft: HRESULT values in MS-ERREF
Looking for a different code? Search another status or error code.