| Previous | Next |
| MQ_INFORMATION_PROPERTY | MQ_INFORMATION_PROPERTY_IGNORED |
MQ_INFORMATION_ILLEGAL_PROPERTY
Why the exact HRESULT matters
MQ_INFORMATION_ILLEGAL_PROPERTY 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 invalid property identifier reported as a warning. Map the failing aStatus element back to its aPropID; the remaining properties may still have been processed.
MSMQ property structures can include an optional status array parallel to the property identifiers and values. When diagnosing this result, A nonfatal top-level result therefore does not replace inspection of individual entries.
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 | invalid property identifier reported as a warning |
| Primary recovery rule | Remove or replace only the unsupported identifier, then verify the postcondition already produced by the original call. |
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 invalid property identifier reported as a warning.
Minimum useful telemetry
- The matching apropid and mqpropvariant index; associate it explicitly with this result.
- When diagnosing it, whether an output object or queue was nevertheless created; capture the value before cleanup or retry changes it.
- In the path, the function result and every entry of the optional astatus array; 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 the function result and every entry of the optional aStatus array.
- Capture the matching aPropID and MQPROPVARIANT index.
- 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: Remove or replace only the unsupported identifier, then verify the postcondition already produced by the original call.
Retry and cleanup
Remove or replace only the unsupported identifier, then verify the postcondition already produced by the original call.
When diagnosing it, the retry decision must account for side effects that may already exist., query queue, message, directory, or transaction state first whenever the result leaves completion uncertain.
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 invalid property identifier reported as a 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 queue provisioning tool encounters it. It records both the successful primary effect and the property warning, then corrects only the affected field.
Automated coverage should preserve the original arrays/identities, confirm that cleanup is safe after it, and test that a retry does not duplicate messages or directory objects.
References
- Microsoft: queue properties and MQQUEUEPROPS — source used for the result analysis.
- 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.
Looking for a different code? Search another status or error code.