COMQC_E_APPLICATION_NOT_QUEUED (0X80110600): Fix Queued Moniker Error

Getting 0X80110600 with the message "Only COM+ applications marked 'queued' can be invoked using the 'queue' moniker" is frustrating—especially when you're sure you set everything up right. Let's cut to the chase: this error means your COM+ application doesn't have queuing enabled, or the component inside it isn't marked as supporting queued calls. Here's the fix, why it works, and what to check when the obvious isn't enough.

The Quick Fix: Enable Queuing

1. Open Component Services — hit Win+R, type comexp.msc.
2. Navigate to Component Services > Computers > My Computer > COM+ Applications.
3. Right-click your application, choose Properties.
4. Go to the Queuing tab.
5. Check Queued — This application can be reached by MSMQ queue clients.
6. Under Application — Allows queued components that use the queue moniker, make sure it's also checked.
7. Click OK. Then restart the application (right-click > Shut Down, then right-click > Start).

That's it for 90% of cases. But if you still see the error, the problem is inside the component itself.

Verify the Component Supports Queuing

Open your application in the tree, expand Components. Right-click the component you're trying to invoke via the queue moniker, go to Properties > Queuing. The checkbox Queued must be checked. If it's grayed out, the component's interface doesn't support queuing—you'll need to add the QUEUEABLE attribute to the interface definition in IDL, or use a different component.

Why This Fix Works

The queue moniker (queue:/new:ProgId or similar) tells COM+ to route calls through Message Queuing (MSMQ) instead of direct RPC. COM+ internally checks two flags before accepting the moniker:

• The application-level flag: COM+_APPLICATION_QUEUED — set via the Queuing tab.
• The component-level flag: COM+_COMPONENT_QUEUEABLE — set via the component's Queuing tab.

If either flag is missing, COM+ returns COMQC_E_APPLICATION_NOT_QUEUED (0x80110600). The reason both must be set is architectural: MSMQ delivery is async, so the component must be stateless and its methods must not return values (void). The queue listener deserializes the call and invokes it on a separate thread—if the interface isn't designed for that, you'd get corrupted state or deadlocks. Microsoft chose to enforce this at the configuration level rather than letting you crash at runtime.

Less Common Variations

1. MSMQ Not Installed

Queued components depend on MSMQ. On Windows 10/11, MSMQ isn't installed by default. Check: Control Panel > Programs > Turn Windows features on or off > Microsoft Message Queue (MSMQ) Server. Enable it and reboot. Without MSMQ, the application will start but any queue moniker invocation fails with this exact error—because the underlying queue infrastructure doesn't exist.

2. Application Pool Identity Mismatch

If your COM+ app is running under a specific identity (not the interactive user), that identity needs permissions on the MSMQ private queue. Check Computer Management > Services and Applications > Message Queuing > Private Queues. Find the queue named after your application GUID, right-click > Properties > Security. Add the COM+ identity with Full Control. I've seen this trip people up when they switch from "Interactive User" to a domain service account—the queue gets created, but only the original user can write to it.

3. 32-bit vs 64-bit Mismatch

If your component is 32-bit and you're on a 64-bit system, COM+ runs in 32-bit mode by default. But if your calling code is 64-bit, the queue moniker resolves to the wrong application folder. In Component Services > Properties > Advanced, check Compress and Process type — make sure it's set to "Server application" with the correct bitness. The error message won't tell you this, but I've seen it happen when someone migrates an old VB6 COM+ app to a modern server.

Prevention

• Design for queuing from the start. If you know a component will be called asynchronously, mark it queued in the IDL: [queueable] on the interface. Retroactively adding queuing to a stateful component is painful—you'll likely need to refactor methods to return nothing and pass all data as parameters.
• Document the MSMQ dependency. Put it in your deployment checklist: “Verify MSMQ installed, COM+ app queued, component queued, queue permissions granted.” I add this as a comment in the setup script.
• Test with the queue moniker in your CI pipeline. Don't just test direct calls. Write a unit test that invokes the component via queue:/new:... and checks for a success HRESULT. Catches this before it hits production.

That's the full picture. The error is COM+ being pedantic about its queuing contract—respect the flags and it works every time.