| Previous | Next |
| MQ_ERROR_STALE_HANDLE | MQ_ERROR_QUEUE_DELETED |
MQ_ERROR_TRANSACTION_ENLIST
Why the exact HRESULT matters
When MQ_ERROR_TRANSACTION_ENLIST appears, start with the queue operation and its property arrays rather than with a broad repair of the Message Queuing service. In this case the decisive subject is resource enlistment into the selected transaction failed. The transaction exists, but MSMQ could not join it as a participant.
For MQ_ERROR_TRANSACTION_ENLIST, A transaction error can occur before enlistment, during resource-manager participation, or after the application has issued work but before the outcome is durable. When diagnosing MQ_ERROR_TRANSACTION_ENLIST, retry policy must account for an uncertain commit result.
Transaction identifiers and completion ownership are essential. In the MQ_ERROR_TRANSACTION_ENLIST path, two threads attempting to commit, abort, or consume the same locked message can turn a recoverable application bug into duplicate processing.
Subsystem context
| Subsystem | MSMQ internal or coordinated transactions and their MS DTC enlistment |
|---|---|
| Decisive boundary | transaction type, queue locality, operation order, and enlistment state determine whether the action is legal |
| Code-specific focus | resource enlistment into the selected transaction failed |
| Primary recovery rule | Collect DTC enlistment diagnostics and verify transaction state before any retry. |
When diagnosing MQ_ERROR_TRANSACTION_ENLIST, A transport retry is not equivalent to transaction recovery. In the MQ_ERROR_TRANSACTION_ENLIST path, first determine whether the unit of work committed, aborted, remains in doubt, or never enlisted. For MQ_ERROR_TRANSACTION_ENLIST, the code-specific boundary is resource enlistment into the selected transaction failed.
Minimum useful telemetry
- Queue transactional flag and local/remote placement; associate it explicitly with
MQ_ERROR_TRANSACTION_ENLIST. - When diagnosing
MQ_ERROR_TRANSACTION_ENLIST, begin, enlist, send/receive, prepare, commit, and abort timestamps; capture the value before cleanup or retry changes it. - In the
MQ_ERROR_TRANSACTION_ENLISTpath, transaction identifier and whether it is internal, ambient, or dtc-coordinated; compare it with a known-good call using the same account and queue type. - For this
MQ_ERROR_TRANSACTION_ENLISTresult, record the queue path or format name, local/remote placement, transactional flag, caller SID, process build, and UTC correlation ID when they apply.
For MQ_ERROR_TRANSACTION_ENLIST, log certificate thumbprints, provider names, SIDs, GUIDs, lengths, and hashes where useful, but do not log private keys, symmetric keys, credentials, or confidential message bodies.
Step-by-step diagnosis
- Record the unsigned HRESULT,
MQ_ERROR_TRANSACTION_ENLIST, and the native API or COM method before a framework replaces it with a generic exception. - Reproduce with the smallest queue/message/property set that still returns
MQ_ERROR_TRANSACTION_ENLIST; change one precondition at a time. - In the
MQ_ERROR_TRANSACTION_ENLISTpath, verify the postcondition after the failed call: queue existence, message presence, directory object state, transaction outcome, or generated output may differ by result. - For this
MQ_ERROR_TRANSACTION_ENLISTresult, capture transaction identifier and whether it is internal, ambient, or DTC-coordinated. - For
MQ_ERROR_TRANSACTION_ENLIST, capture queue transactional flag and local/remote placement. - When diagnosing
MQ_ERROR_TRANSACTION_ENLIST, apply the code-specific recovery rule: Collect DTC enlistment diagnostics and verify transaction state before any retry.
Retry and cleanup
Collect DTC enlistment diagnostics and verify transaction state before any retry.
When diagnosing MQ_ERROR_TRANSACTION_ENLIST, an immediate loop around the same call is not recovery. In the MQ_ERROR_TRANSACTION_ENLIST path, define who owns cancellation, handle recreation, transaction reconciliation, and duplicate suppression before another attempt is issued.
Avoiding a false diagnosis
In the MQ_ERROR_TRANSACTION_ENLIST path, do not convert the operation to a nontransactional send merely to suppress the HRESULT; that changes delivery and atomicity guarantees. The specific focus for MQ_ERROR_TRANSACTION_ENLIST remains resource enlistment into the selected transaction failed.
- In the
MQ_ERROR_TRANSACTION_ENLISTpath, A successful test under an interactive administrator account does not prove that the production service account has the same profile, token, directory access, or key permissions. - For this
MQ_ERROR_TRANSACTION_ENLISTresult, restarting MSMQ before collecting evidence can invalidate handles and erase the first useful event; it is a containment action, not a root-cause diagnosis.
Example
A transactional receiver encounters MQ_ERROR_TRANSACTION_ENLIST. For MQ_ERROR_TRANSACTION_ENLIST, it correlates the MSMQ call with the DTC transaction ID and final outcome before replaying business work. When diagnosing MQ_ERROR_TRANSACTION_ENLIST, the acceptance test then changes only the decisive precondition and confirms both the HRESULT and the actual queue/message state.
Automated coverage should preserve the original arrays/identities, confirm that cleanup is safe after MQ_ERROR_TRANSACTION_ENLIST, and test that a retry does not duplicate messages or directory objects.
References
- Microsoft: enable MS DTC diagnostic tracing — source used for the
MQ_ERROR_TRANSACTION_ENLISTanalysis. - Microsoft: destination queues — source used for the
MQ_ERROR_TRANSACTION_ENLISTanalysis. - Microsoft: Message Queuing error and information codes — source used for the
MQ_ERROR_TRANSACTION_ENLISTanalysis. - Microsoft: MSMQTransaction.Commit and transaction model links — source used for the
MQ_ERROR_TRANSACTION_ENLISTanalysis. - Microsoft: DTC Developers Guide — source used for the
MQ_ERROR_TRANSACTION_ENLISTanalysis.
Looking for a different code? Search another status or error code.