MSMQ generates 0xC00E001D when no applications should be receiving messages anyway

Had a support problem recently which took a while to crack and thought I'd share. 

The customer had a Trigger on a queue that would peek (but not receive) the message. At the end of the day all the messages would be manually purged ready for the next day. 

Everything would be fine for weeks until the Trigger service would stop responding after logging an event 65527 ("The call to MQReceiveMessage() has failed with a HRESULT of (C00E001D). The queue name was (server\private$\queue).") The HResult 0xC00E001D means MQ_ERROR_MESSAGE_ALREADY_RECEIVED, which is weird as in the customer's system nothing actually receives the messages - they are only peeked at. The Triggers service in Windows 2000 was not coded to continue after this error (although newer versions are) so the service had to be restarted.

Looking at performance monitor logs we noticed that the total number of messages in the queue didn't consistently go up throughout the day - occasionally there would be a slight drop in the graph before continuing up again.

This anomaly was explained by the customer's use of an arbitrary short TimeToBeReceived on certain messages that went into the queue. These messages would expire over time and be removed by the MSMQ service. At particularly busy times of the day, the Triggers service would not get round to processing the messages before they expired, resulting in MQ_ERROR_MESSAGE_ALREADY_RECEIVED.

Solution was to change the TTBR as it wasn't required anyway.

Comments (0)

Skip to main content