Fix COMQC_E_UNAUTHENTICATED (0X80110605) in Queued Components

This error is a pain—I know

You've got a COM+ queued component application running, everything was fine, and then 0X80110605 pops up: "An unauthenticated message was received by an application that accepts only authenticated messages." Your app stops processing messages, and you're stuck. Let's fix it.

The fix: align COM+ security with authentication expectations

The error means your queued component app has authentication turned on, but the incoming message from MSMQ lacks proper authentication credentials. You have two paths: enable authentication for the message source, or turn authentication off on the receiver. I'll give you both.

Option 1: Disable authentication on the COM+ application (easier, local testing)

Skip this for production—it's a security drop. But for troubleshooting or non-sensitive environments, it works.

1. Open Component Services (run dcomcnfg).
2. Expand Component Services > Computers > My Computer > COM+ Applications.
3. Right-click your queued application and select Properties.
4. Go to the Security tab.
5. Under Authentication Level for Calls, change it from Packet (or higher) to None.
6. Click OK, then restart the application (right-click > Shut down, then Start).

Test your message flow. If the error stops, you've confirmed the issue is authentication mismatch. Now you can decide if you want to keep it off or fix the source.

Option 2: Require authentication at the message source (production fix)

This is the right move for secure environments. The sender must authenticate to MSMQ before sending queued messages.

• Make sure both sender and receiver are on the same domain (or have mutual trust).
• On the sender machine, configure MSMQ to use Windows authentication when sending to the queue. This is typically done via code—ensure your sending component uses MessageQueue.Send with MessageQueueTransactionType.Single or Automatic, and the sender's process runs under a domain account.
• Check the queue's security: open Computer Management > Services and Applications > Message Queuing > Private Queues (or public). Right-click the target queue > Properties > Security. Add the sender's machine account or domain user with Send Message permission.
• Reboot or restart MSMQ service: net stop msmq && net start msmq.

Why this works

COM+ Queued Components use MSMQ under the hood. When you set the COM+ application's authentication level to something stricter than None, it tells the COM+ runtime to reject any incoming messages that lack an authenticated sender. MSMQ messages are not authenticated by default unless the sending code explicitly calls for it or the sender's process identity is trusted. Option 1 removes that check; Option 2 ensures the sender supplies the required ticket.

This tripped me up the first time too—I had a Windows Server 2019 machine where a legacy app worked fine on Windows 7 but started throwing 0X80110605 after an upgrade. The old app was sending messages without authentication, and the new COM+ defaults in Server 2019 are stricter.

Less common variations

Variation A: Message arrives with null security

If the sender is a non-Windows system (Linux, Python script, etc.) using MSMQ via HTTP, the message might lack any security context. You'll see the same error. Solution? Wrap the sender in a Windows service that uses System.Messaging.MessageQueue.Send with a domain account, or set authentication to None on the COM+ app (Option 1).

Variation B: COM+ application identity mismatch

Check your COM+ application's Identity tab. If it's set to a specific user account, that account must have permissions to read from the queue. If the identity doesn't match the queue's security, you get this error even if the sender is authenticating. Fix: set identity to Interactive User (for testing) or a dedicated service account with full control on the queue.

Variation C: MSMQ dead-letter queue misconfiguration

Sometimes the error appears in the event log, but the actual cause is that MSMQ's dead-letter queue is full or misconfigured. Clear it: net stop msmq, delete %windir%\system32\msmq\storage contents (back up first), then net start msmq. This is rare but I've seen it on busy systems.

Preventing future occurrences

• Standardize authentication: Decide once—either all senders authenticate, or nobody does. Document it. Don't mix.
• Use domain service accounts for both sender and receiver COM+ applications. This avoids identity mismatches.
• Test in a staging environment with the same Windows version as production. I've seen this error pop up only after a Windows Update changed default authentication levels (KB5006670 on Server 2022 did this).
• Monitor event logs for MSMQ events (Microsoft-Windows-MSMQ/Operational) which often hint at authentication problems before the COM+ error surfaces.

That's it. Pick the fix that fits your security posture, and you'll be processing messages again in minutes.