What does HRESULT 0xC00E005A (MQ_ERROR_QUEUE_DELETED) mean?

 
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

Subsystemqueue and handle lifetime across deletion, service restart, asynchronous reads, and competing consumers
Decisive boundaryan object that was valid when opened may no longer identify the same queue-manager generation or message
Code-specific focusopen handle refers to a queue that has been deleted
Primary recovery ruleClose 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_DELETED path, 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_DELETED result, 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

  1. Record the unsigned HRESULT, MQ_ERROR_QUEUE_DELETED, and the native API or COM method before a framework replaces it with a generic exception.
  2. Reproduce with the smallest queue/message/property set that still returns MQ_ERROR_QUEUE_DELETED; change one precondition at a time.
  3. In the MQ_ERROR_QUEUE_DELETED path, verify the postcondition after the failed call: queue existence, message presence, directory object state, transaction outcome, or generated output may differ by result.
  4. For this MQ_ERROR_QUEUE_DELETED result, capture handle creation time and MSMQ service restart time.
  5. For MQ_ERROR_QUEUE_DELETED, capture queue deletion/recreation events and current format name.
  6. 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_DELETED path, 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_DELETED result, granting broad queue or certificate permissions may mask the symptom while creating a security defect. For MQ_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


Looking for a different code? Search another status or error code.