| Previous | Next |
| MQ_ERROR_QUEUE_NOT_AVAILABLE | MQ_ERROR_TRANSACTION_IMPORT |
MQ_ERROR_DTC_CONNECT
Why the exact HRESULT matters
Applications should keep MQ_ERROR_DTC_CONNECT attached to the exact MSMQ call that produced it; translating it immediately to “queue error” discards the diagnostic boundary. Its diagnostic boundary is MSMQ cannot establish an MS DTC relationship. The failure occurs before a coordinated transaction can be used by the queue operation.
MSMQ supports internal single-queue transactions and coordinated transactions involving MS DTC. When diagnosing this result, queue type, destination locality, receive locality, and ambient transaction propagation constrain which operations are valid.
Transaction identifiers and completion ownership are essential., 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 | MSMQ cannot establish an MS DTC relationship |
| Primary recovery rule | Check DTC service, security, name resolution, RPC/firewall, and mutual authentication before changing queue type. |
When diagnosing this result, A transport retry is not equivalent to transaction recovery., first determine whether the unit of work committed, aborted, remains in doubt, or never enlisted. The code-specific boundary is MSMQ cannot establish an MS DTC relationship.
Minimum useful telemetry
- Queue transactional flag and local/remote placement; associate it explicitly with this result.
- When diagnosing this result, begin, enlist, send/receive, prepare, commit, and abort timestamps; capture the value before cleanup or retry changes it.
- In the path, 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.
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, it, and the native API or COM method before a framework replaces it with a generic exception.
- When diagnosing it, capture transaction identifier and whether it is internal, ambient, or DTC-coordinated.
- In the path, capture queue transactional flag and local/remote placement.
- verify the postcondition after the failed call: queue existence, message presence, directory object state, transaction outcome, or generated output may differ by result.
- When diagnosing it, apply the code-specific recovery rule: Check DTC service, security, name resolution, RPC/firewall, and mutual authentication before changing queue type.
Retry and cleanup
Check DTC service, security, name resolution, RPC/firewall, and mutual authentication before changing queue type.
When diagnosing it, the retry decision must account for side effects that may already exist., query queue, message, directory, or transaction state first whenever the result leaves completion uncertain.
Avoiding a false diagnosis
In the 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 it remains MSMQ cannot establish an MS DTC relationship.
- In the path, 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.
- 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 dtc-coordinated workflow encounters it. It correlates the MSMQ call with the DTC transaction ID and final outcome before replaying business work.
A regression test should force it, assert the raw value and relevant outputs, then correct only the documented precondition and verify the intended success or neighboring HRESULT.
References
- Microsoft: MSMQTransaction.Commit and transaction model links — source used for the result analysis.
- Microsoft: DTC Developers Guide — source used for the result analysis.
- Microsoft: enable MS DTC diagnostic tracing — source used for the result analysis.
- Microsoft: destination queues — source used for the result analysis.
- Microsoft: Message Queuing error and information codes — source used for the result analysis.
Looking for a different code? Search another status or error code.