| Previous | Next |
| XACT_E_NOTRANSACTION | XACT_E_UNKNOWNRMGRID |
XACT_E_NOTSUPPORTED
XACT_E_NOTSUPPORTED is the failure HRESULT 0x8004D00F (signed decimal -2147168241, unsigned decimal 2147799055). Its severity bit is 1, facility is 4 (FACILITY_ITF), and the facility-specific code field is 0xD00F.
The individual options may exist, but their combination is invalid
AllStat and the Windows SDK describe this HRESULT as an invalid combination of flags. The important distinction is that one flag is not necessarily unknown: the transaction implementation rejects the combined mode requested by the caller.
AllStat records the Windows message as: “An invalid combination of flags was specified” This text should be interpreted at the transaction stage described below rather than as a generic COM failure.
The contract boundary to identify
The failure belongs to option validation at the method boundary. Examples can involve retaining behavior, asynchronous completion, phase controls, or implementation-specific choices, but the raw HRESULT alone does not identify which pair or group conflicts. The exact flags and method contract are therefore essential evidence.
Likely causes to separate
- A wrapper ORs together options that are valid only in mutually exclusive modes.
- Flags intended for commit are reused on abort, enlistment, or transaction creation.
- A newer caller sends an option combination to an older proxy or provider implementation.
- Default framework flags interact with explicit application flags and create an unintended combined value.
Evidence worth preserving
- Log the complete numeric flag mask and decode every set bit using the header version used to build the caller.
- Record the exact interface and method because identical bit positions do not imply identical semantics elsewhere.
- Capture whether the transaction is local, promoted, nested, or imported.
- Preserve both explicit options and defaults added by libraries between the application and MSDTC.
Diagnostic sequence
- Compare the mask with the documented allowed combinations for the returning method.
- Remove one option at a time in a test environment to identify the minimal conflicting set.
- Check binary and header version skew if the symbolic decode does not match runtime behavior.
- After selecting a supported mode, verify that completion, notification, and retention behavior still meet the caller’s requirements.
Retry and recovery
Construct a supported option set and retry only before the operation has begun. Do not repeatedly resubmit the same mask. If the application depends on the rejected combined semantics, redesign the transaction flow instead of silently dropping whichever bit is easiest.
What this HRESULT does not establish
The HRESULT does not reveal the offending bit and should not be interpreted as “the entire transaction API is unsupported.” It also does not establish that the transaction was aborted.
Difference from nearby transaction results
E_INVALIDARG usually identifies a malformed argument, while this XACT result points to transaction options whose combination is not supported. XACT_E_NOASYNC and XACT_E_NOTIMEOUT identify narrower capability failures.
Practical scenario
A compatibility layer combines a retaining option with an asynchronous completion flag. The target transaction implementation rejects the pair. The developer logs the original mask, selects a synchronous nonretaining path, and adds a capability test for future versions.
Guidance for software and telemetry
Store raw masks in telemetry alongside decoded names. Avoid boolean configuration fields that are merged far from the call site, because they hide how the invalid combination was formed.
Official Microsoft references
- Microsoft: COM transaction error codes
- Microsoft: ITransaction
- Microsoft: DTC interfaces
- Microsoft: HRESULT values in MS-ERREF
Looking for a different code? Search another status or error code.