| Previous | Next |
| MQ_ERROR_TRANSACTION_ENLIST | MQ_ERROR_ILLEGAL_CONTEXT |
MQ_ERROR_QUEUE_DELETED
Operational meaning
The important part of MQ_ERROR_QUEUE_DELETED is not only whether the call failed, but which MSMQ subsystem had enough information to return this specific result. Interpret it as open handle refers to a queue that has been deleted, not as a general transport outage. Recreating a queue with the same path does not make the old handle valid.
For MQ_ERROR_QUEUE_DELETED, reopening by the same path after deletion can identify a new queue object. When diagnosing MQ_ERROR_QUEUE_DELETED, the application must decide whether resuming against that new object is safe or whether the work item belongs to the old generation.
When diagnosing MQ_ERROR_QUEUE_DELETED, for asynchronous or transactional reads, cleanup must be coordinated with callback and transaction owners. In the MQ_ERROR_QUEUE_DELETED path, closing a handle from another thread can be the cause rather than the cure.
Where to draw the boundary
| Subsystem | queue and handle lifetime across deletion, service restart, asynchronous reads, and competing consumers |
|---|---|
| Decisive boundary | an object that was valid when opened may no longer identify the same queue-manager generation or message |
| Code-specific focus | open handle refers to a queue that has been deleted |
| Primary recovery rule | Close it, resolve the intended new queue, and reopen explicitly. |
When diagnosing MQ_ERROR_QUEUE_DELETED, the same pathname does not prove object identity across restart or recreation. In the MQ_ERROR_QUEUE_DELETED path, handles and message lookup IDs belong to a particular lifetime. For MQ_ERROR_QUEUE_DELETED, the code-specific boundary is open handle refers to a queue that has been deleted.
Evidence to preserve
- Queue deletion/recreation events and current format name; associate it explicitly with
MQ_ERROR_QUEUE_DELETED. - When diagnosing
MQ_ERROR_QUEUE_DELETED, lookup id, cursor action, transaction, and competing consumer activity; capture the value before cleanup or retry changes it. - In the
MQ_ERROR_QUEUE_DELETEDpath, handle creation time and msmq service restart time; compare it with a known-good call using the same account and queue type. - For this
MQ_ERROR_QUEUE_DELETEDresult, 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_QUEUE_DELETED, 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.
Diagnostic sequence
- Record the unsigned HRESULT,
MQ_ERROR_QUEUE_DELETED, 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_QUEUE_DELETED; change one precondition at a time. - In the
MQ_ERROR_QUEUE_DELETEDpath, 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_QUEUE_DELETEDresult, capture handle creation time and MSMQ service restart time. - For
MQ_ERROR_QUEUE_DELETED, capture queue deletion/recreation events and current format name. - When diagnosing
MQ_ERROR_QUEUE_DELETED, apply the code-specific recovery rule: Close it, resolve the intended new queue, and reopen explicitly.
Handling and recovery
Close it, resolve the intended new queue, and reopen explicitly.
When diagnosing MQ_ERROR_QUEUE_DELETED, the retry decision must account for side effects that may already exist. In the MQ_ERROR_QUEUE_DELETED path, query queue, message, directory, or transaction state first whenever the result leaves completion uncertain.
Nearby failure boundaries
In the MQ_ERROR_QUEUE_DELETED path, reusing the same pathname after restart or recreation does not revive the old handle, lookup identifier, message lock, or transaction context. The specific focus for MQ_ERROR_QUEUE_DELETED remains open handle refers to a queue that has been deleted.
- In the
MQ_ERROR_QUEUE_DELETEDpath, restarting MSMQ before collecting evidence can invalidate handles and erase the first useful event; it is a containment action, not a root-cause diagnosis. - For this
MQ_ERROR_QUEUE_DELETEDresult, granting broad queue or certificate permissions may mask the symptom while creating a security defect. ForMQ_ERROR_QUEUE_DELETED, test the exact identity and access needed by the operation.
Worked example
A long-running consumer encounters MQ_ERROR_QUEUE_DELETED. For MQ_ERROR_QUEUE_DELETED, it closes invalid objects, resolves the current queue generation, and reconciles whether another consumer completed the work. When diagnosing MQ_ERROR_QUEUE_DELETED, the acceptance test then changes only the decisive precondition and confirms both the HRESULT and the actual queue/message state.
A regression test should force MQ_ERROR_QUEUE_DELETED, assert the raw value and relevant outputs, then correct only the documented precondition and verify the intended success or neighboring HRESULT.
References
- Microsoft: MQReceiveMessage — source used for the
MQ_ERROR_QUEUE_DELETEDanalysis. - Microsoft: MQReceiveMessageByLookupId — source used for the
MQ_ERROR_QUEUE_DELETEDanalysis. - Microsoft Open Specifications: Queue Manager Remote Read Protocol — source used for the
MQ_ERROR_QUEUE_DELETEDanalysis. - Microsoft: Message Queuing error and information codes — source used for the
MQ_ERROR_QUEUE_DELETEDanalysis.
Looking for a different code? Search another status or error code.