| Previous | Next |
| MQ_ERROR_MESSAGE_NOT_AUTHENTICATED | ERROR_GRAPHICS_SESSION_TYPE_CHANGE_IN_PROGRESS |
MQ_ERROR_MESSAGE_LOCKED_UNDER_TRANSACTION
Why the exact HRESULT matters
MQ_ERROR_MESSAGE_LOCKED_UNDER_TRANSACTION belongs to the Message Queuing HRESULT facility, but its useful meaning is narrower than a generic messaging failure. In this case the decisive subject is message is reserved by an unresolved transaction. Until commit or abort, another transaction cannot consume or move the same message.
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 | message is reserved by an unresolved transaction |
| Primary recovery rule | Find the owning transaction and wait/recover it; duplicate consumers cannot force the lock away. |
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 message is reserved by an unresolved transaction.
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 begin, enlist, send/receive, prepare, commit, and abort timestamps.
- In the path, capture transaction identifier and whether it is internal, ambient, or DTC-coordinated.
- 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: Find the owning transaction and wait/recover it; duplicate consumers cannot force the lock away.
Retry and cleanup
Find the owning transaction and wait/recover it; duplicate consumers cannot force the lock away.
When diagnosing it, do not hide this HRESULT behind an unlimited framework retry., require a verified precondition change and preserve the original correlation identifier across the next attempt.
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 message is reserved by an unresolved transaction.
- 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
An order processor using msmq and sql 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.