| Previous | Next |
| MQ_INFORMATION_INTERNAL_USER_CERT_EXIST | ERROR_GRAPHICS_PARTIAL_DATA_POPULATED |
MQ_INFORMATION_OWNER_IGNORED
Why the exact HRESULT matters
MQ_INFORMATION_OWNER_IGNORED belongs to the Message Queuing HRESULT facility, but its useful meaning is narrower than a generic messaging failure. Its diagnostic boundary is security update with owner field omitted or ignored. MQSetQueueSecurity processed the requested security information but did not replace the owner.
For MQ_INFORMATION_OWNER_IGNORED, informational HRESULTs are especially easy to mishandle in wrappers that treat every nonzero value as an exception. When diagnosing MQ_INFORMATION_OWNER_IGNORED, the caller must first determine whether the documented operation and its side effects already completed.
When diagnosing MQ_INFORMATION_OWNER_IGNORED, A warning returned from a queue or message property call can describe only one element while the other elements and the primary operation succeeded. In the MQ_INFORMATION_OWNER_IGNORED path, preserve both the returned object state and the element-level status.
Subsystem context
| Subsystem | the per-property status channel used by MSMQ APIs |
|---|---|
| Decisive boundary | the call may complete while one array element is rejected, ignored, duplicated, or still pending |
| Code-specific focus | security update with owner field omitted or ignored |
| Primary recovery rule | Read the resulting security descriptor and verify DACL/SACL changes separately from ownership. |
When diagnosing MQ_INFORMATION_OWNER_IGNORED, unlike an error HRESULT, this informational value can accompany a completed operation. In the MQ_INFORMATION_OWNER_IGNORED path, it must still be handled because ignored or duplicate properties can change the stored result. For MQ_INFORMATION_OWNER_IGNORED, the code-specific boundary is security update with owner field omitted or ignored.
Minimum useful telemetry
- Whether an output object or queue was nevertheless created; associate it explicitly with
MQ_INFORMATION_OWNER_IGNORED. - When diagnosing
MQ_INFORMATION_OWNER_IGNORED, the function result and every entry of the optional astatus array; capture the value before cleanup or retry changes it. - In the
MQ_INFORMATION_OWNER_IGNOREDpath, the matching apropid and mqpropvariant index; compare it with a known-good call using the same account and queue type. - For this
MQ_INFORMATION_OWNER_IGNOREDresult, 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_INFORMATION_OWNER_IGNORED, 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_INFORMATION_OWNER_IGNORED, and the native API or COM method before a framework replaces it with a generic exception. - When diagnosing
MQ_INFORMATION_OWNER_IGNORED, verify the postcondition after the failed call: queue existence, message presence, directory object state, transaction outcome, or generated output may differ by result. - Capture the matching aPropID and MQPROPVARIANT index.
- For this
MQ_INFORMATION_OWNER_IGNOREDresult, capture whether an output object or queue was nevertheless created. - Reproduce with the smallest queue/message/property set that still returns
MQ_INFORMATION_OWNER_IGNORED; change one precondition at a time. - When diagnosing
MQ_INFORMATION_OWNER_IGNORED, apply the code-specific recovery rule: Read the resulting security descriptor and verify DACL/SACL changes separately from ownership.
Retry and cleanup
Read the resulting security descriptor and verify DACL/SACL changes separately from ownership.
When diagnosing MQ_INFORMATION_OWNER_IGNORED, do not hide this HRESULT behind an unlimited framework retry. In the MQ_INFORMATION_OWNER_IGNORED path, require a verified precondition change and preserve the original correlation identifier across the next attempt.
Avoiding a false diagnosis
In the MQ_INFORMATION_OWNER_IGNORED path, do not treat a nonzero informational HRESULT as proof that the primary operation failed. For this MQ_INFORMATION_OWNER_IGNORED result, verify the completed effect and the individual property status. The specific focus for MQ_INFORMATION_OWNER_IGNORED remains security update with owner field omitted or ignored.
- In the
MQ_INFORMATION_OWNER_IGNOREDpath, 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_INFORMATION_OWNER_IGNOREDresult, 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 native c++ sender encounters MQ_INFORMATION_OWNER_IGNORED. For MQ_INFORMATION_OWNER_IGNORED, it records both the successful primary effect and the property warning, then corrects only the affected field. When diagnosing MQ_INFORMATION_OWNER_IGNORED, 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_INFORMATION_OWNER_IGNORED, assert the raw value and relevant outputs, then correct only the documented precondition and verify the intended success or neighboring HRESULT.
References
- Microsoft: MSMQ message properties — source used for the
MQ_INFORMATION_OWNER_IGNOREDanalysis. - Microsoft: Message Queuing overview — source used for the
MQ_INFORMATION_OWNER_IGNOREDanalysis. - Microsoft: Message Queuing error and information codes — source used for the
MQ_INFORMATION_OWNER_IGNOREDanalysis. - Microsoft: queue properties and MQQUEUEPROPS — source used for the
MQ_INFORMATION_OWNER_IGNOREDanalysis.
Looking for a different code? Search another status or error code.