| Previous | Next |
| COMQC_E_NO_IPERSISTSTREAM | COMQC_E_UNAUTHENTICATED |
COMQC_E_BAD_MESSAGE
This code places the first failure in queued-component message integrity. Operationally, the listener received a queued-component message whose recording format is malformed, truncated, incompatible, or damaged.
Start with the failing layer
Queued Components cross several independent layers: call recording, MSMQ transport, message authentication, listener playback, and execution of the business method when diagnosing queued-component message integrity. Message ID, queue format name, original sender, any mover or requeuer, and the COM+ application version are the keys that join those layers without treating every queue symptom as the same fault for an incident involving queued-component message integrity.
Do not collapse this result into a nearby status. Business-method failure happens after a message is decoded; this result means COM+ could not trust or interpret the recorded call. For queued-component message integrity, compare the lifecycle stage, object identity, caller context, and first returning API—not only the English wording or the final dialog shown to the user.
Preserve before retrying
| Preserve before changing state | Diagnostic value |
|---|---|
| Original MSMQ message ID, class, body size/hash, label, extension, and authentication fields | Locates the exact attempt and prevents evidence from a later retry from being mixed into it when diagnosing queued-component message integrity. |
| Sender component/type-library version and listener version | Separates a contract or configuration defect from a transient environmental failure in an incident involving queued-component message integrity. |
| Dead-letter or exception queue routing and movement history | Provides a stable comparison point for a controlled reproduction before changing the state involved in queued-component message integrity. |
| First parser error in the COM+ listener before the message is retried or moved | Shows whether the proposed correction changes the first failing boundary during verification of queued-component message integrity. |
Collect the smallest evidence set that identifies the attempt and object when diagnosing queued-component message integrity. Redact secrets and message contents; preserve hashes, IDs, policy values, versions, and state transitions instead for an incident involving queued-component message integrity.
Three useful comparisons
- Replay a preserved copy in an isolated queue without editing it; use a disposable or backed-up environment when the comparison changes boot, security, device, queue, or encryption state.
- Send a known-good call from the same sender build to the same listener; retain one negative control so that a broad workaround is not mistaken for a root-cause correction.
- Compare message body length and version fields across producer deployments; keep every other input fixed and record the first event that differs from the failing run.
For queued-component message integrity, do not use repeated retries as the primary test. In the queued-component message integrity case, a successful later attempt may reflect a new object, refreshed policy, restarted service, different token, or completed background transition, so record exactly what changed between attempts.
Decision points
Use the outcomes to narrow the layer rather than to accumulate unrelated fixes for queued-component message integrity:
| Observed result | Interpretation |
|---|---|
| The minimal or known-good comparison succeeds | For queued-component message integrity, the platform path is available; concentrate on the production object, arguments, identity, policy, or lifecycle state described above. |
| The control fails at the same first operation | For queued-component message integrity, failure of the control points below application-specific data; preserve service, provider, operating-system, or host evidence before changing the environment. |
| A different HRESULT appears after one controlled change | The queued-component message integrity boundary moved; diagnose the new status separately rather than treating it as confirmation that the entire operation is fixed. |
A defensible fix
The corrective action should be narrow: Remove the incompatible producer, restore complete message transport, or provide a version-compatible listener; quarantine rather than endlessly retry poison messages. For queued-component message integrity, preserve the pre-change export or trace and document the exact configuration, build, identity, object, or policy that changed.
Close the incident only when old and new supported senders replay correctly, malformed controls route to the configured exception path, and queue progress continues. For queued-component message integrity, repeat the original supported operation under the original identity and object state, then retain one deliberate boundary or negative test. A result from a different account, simplified input, replacement object, or unrelated machine is useful comparison data for queued-component message integrity, but it is not regression proof.
Technical references
Use these sources for the formal contract, then combine them with evidence from the returning application or service for queued-component message integrity:
- Microsoft: COM error codes.
- Microsoft: using the queue moniker.
- Microsoft: COM+ queued components tasks.
- Microsoft: Message Queuing.
Looking for a different code? Search another status or error code.