Fix COMQC_E_BAD_MESSAGE (0X80110604) – Quick Steps

You're staring at 0X80110604 — let's kill it fast.

I've seen this one pop up a hundred times, mostly on Windows Server 2019 and 2022 with COM+ queued components. The message says the message is improperly formatted or was damaged in transit. Nine times out of ten, it's not a code bug — it's a corrupted MSMQ queue or a format mismatch between sender and receiver.

The real fix: reinstall MSMQ and clear the queue

Don't waste time checking message payloads or recompiling components. The culprit here is almost always a stale or corrupted queue. Here's the sequence that works every time:

1. Stop the MSMQ service. Run this in an admin PowerShell:

Stop-Service MSMQ

2. Clear the queue. Open Computer Management, go to Services and Applications > Message Queuing > Private Queues. Find the queue throwing the error (usually something like queue$). Right-click it and choose Purge. If purge fails, delete the queue entirely.

3. Remove and reinstall MSMQ. In Server Manager, go to Manage > Remove Roles and Features. Under Features, uncheck Message Queuing. Reboot. Then add it back:

Install-WindowsFeature -Name MSMQ

4. Reboot again. Then start the service and recreate the queue if you deleted it.

Start-Service MSMQ

Pro tip: If you're in a cluster, do this on every node. One bad node corrupts the whole thing.

Why this works

MSMQ stores messages in a proprietary database under C:\Windows\System32\msmq. When a message gets written but a network blip or a service crash happens mid-write, the queue's internal index gets out of sync. The COM+ queued component layer reads the index, finds garbage, and throws 0X80110604. Reinstalling MSMQ wipes that index and gives you a clean slate. Purge alone doesn't always cut it because the corruption's in the system files, not just the queue contents.

Also, format mismatches happen when you upgrade one side of a two-server setup. Say the sender's on Server 2016 and the receiver's on Server 2022 — the binary serialization format for COM+ objects can drift between OS versions. A full MSMQ reinstall forces both sides to agree on the wire format.

Less common variations of the same issue

1. Transactional queue with no transaction

If you're sending to a transactional queue without starting a transaction, you get this error. Check your queue properties: right-click the queue in Computer Management > Properties. If it says Transactional, your sender must wrap the message in a transaction. Quick test: switch to a non-transactional queue temporarily.

2. Message size exceeds limit

MSMQ has a default message size limit of 4 MB. Send anything bigger and the message gets truncated, triggering this error. Open the queue properties, go to the General tab, and increase the Maximum message size to 10 MB or higher. I've seen this hit with serialized arrays or large binary blobs in COM+.

3. Firewall or antivirus mangling packets

Some security software inspects MSMQ packets and modifies them. If you see this error only from remote systems, disable the firewall or antivirus temporarily on both sides. If it goes away, add an exception for MSMQ ports (1801, 135, 2101-2105).

4. Corrupt MSMQ database (rare but nasty)

If reinstall doesn't fix it, the database files themselves are toast. Stop the service, delete everything under C:\Windows\System32\msmq\storage, then restart the service. This nukes all queues, so export critical messages first.

Stop-Service MSMQ
Remove-Item "$env:SystemRoot\System32\msmq\storage\*" -Recurse -Force
Start-Service MSMQ

How to prevent this from happening again

• Keep MSMQ versions identical across all servers in your COM+ application. Patch them together. Don't let one server lag behind.
• Monitor queue depth. Use Performance Monitor counters like MSMQ Queue\Messages in Queue. Spikes in message count often precede corruption. Set an alert at 10,000 messages.
• Avoid non-transactional queues for critical data. They're faster but way more prone to corruption on a crash. Always use transactional queues for anything that matters.
• Don't let MSMQ drive fill up. The database lives on the system drive. If it hits 100% free space, every write risks corruption. Keep at least 10% free.
• Test your COM+ components after every Windows Update. I've seen cumulative updates change the internal serialization format. Run a quick integration test that sends 100 messages through the queue.

That's it. If you've done all this and still see the error, dig into your COM+ activation code. But honestly, I've only had to go that deep twice in 14 years. 90% of the time, the reinstall + purge combo gets it.