| Previous | Next |
| MQ_INFORMATION_PROPERTY_IGNORED | MQ_INFORMATION_DUPLICATE_PROPERTY |
MQ_INFORMATION_UNSUPPORTED_PROPERTY
Why the exact HRESULT matters
The important part of MQ_INFORMATION_UNSUPPORTED_PROPERTY is not only whether the call failed, but which MSMQ subsystem had enough information to return this specific result. In this case the decisive subject is version or implementation capability warning. Compare the property with the installed MSMQ version and the concrete operation rather than assuming malformed input.
A warning returned from a queue or message property call can describe only one element while the other elements and the primary operation succeeded. When diagnosing this result, preserve both the returned object state and the element-level status.
When diagnosing this result, informational HRESULTs are especially easy to mishandle in wrappers that treat every nonzero value as an exception., the caller must first determine whether the documented operation and its side effects already completed.
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 | version or implementation capability warning |
| Primary recovery rule | Use a capability-aware fallback and do not expect the ignored value to appear on the stored message or queue. |
When diagnosing this result, unlike an error HRESULT, this informational value can accompany a completed operation., it must still be handled because ignored or duplicate properties can change the stored result. The code-specific boundary is version or implementation capability warning.
Minimum useful telemetry
- Whether an output object or queue was nevertheless created; associate it explicitly with this result.
- When diagnosing it, the function result and every entry of the optional astatus array; capture the value before cleanup or retry changes it.
- In the path, the matching apropid and mqpropvariant index; 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, verify the postcondition after the failed call: queue existence, message presence, directory object state, transaction outcome, or generated output may differ by result.
- In the path, capture the function result and every entry of the optional aStatus array.
- Capture the matching aPropID and MQPROPVARIANT index.
- When diagnosing it, apply the code-specific recovery rule: Use a capability-aware fallback and do not expect the ignored value to appear on the stored message or queue.
Retry and cleanup
Use a capability-aware fallback and do not expect the ignored value to appear on the stored message or queue.
When diagnosing it, an immediate loop around the same call is not recovery., define who owns cancellation, handle recreation, transaction reconciliation, and duplicate suppression before another attempt is issued.
Avoiding a false diagnosis
In the path, do not treat a nonzero informational HRESULT as proof that the primary operation failed. verify the completed effect and the individual property status. The specific focus for it remains version or implementation capability warning.
- 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 native c++ sender encounters it. It records both the successful primary effect and the property warning, then corrects only the affected field.
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: MSMQ message properties — source used for the result analysis.
- Microsoft: Message Queuing overview — source used for the result analysis.
- Microsoft: Message Queuing error and information codes — source used for the result analysis.
- Microsoft: queue properties and MQQUEUEPROPS — source used for the result analysis.
Looking for a different code? Search another status or error code.