A Windows service when trying to access the .Body property of a MSMQ message object throws an EOleException - but only when the Xml document contained in this message has an empty list node.
The EOleException message complains about insufficient memory (exception code -2147024882). Since the exception only occurs with the smallest possible Xml document, memory cannot be the real issue. The next thing that comes to mind is a problem with access rights but then again all "good" messages (as described below) are processed without problems.
The exception can be reproduced under any thinkable condition ("bad" message first, many "good" messages first - then "bad" message, run in debugger or just logging the exception); it doesn't matter if the code shown below is run as a service or as a simple excecutable.
Using the same COM object (MSMQ.MSMQQueueInfo) from within a VBScript on the same machine does not produce any errors.
Accessing any other properties apart from .Body doesn't throw an exception so the message object instance seems to be received sucessfully. Also the transaction receiving the message can be comitted sucessfully if the .Body property is not accessed.
Windows Service code
//...
qInfo := CreateOleObject('MSMQ.MSMQQueueInfo');
qTxDisp := CreateOleObject('MSMQ.MSMQTransactionDispenser');
//...
qTx := qTxDisp.BeginTransaction;
qMessage := qQueue.Receive(qTx, False, True, 0);
//...
sBody := qMessage.Body; //throws EOleException
The qMessage.BodyLength property returns the value 165 for "bad" messages as shown below.
"Bad" message
<?xml version="1.0" encoding="Windows-1252"?>
<response space="" Message="Entry_7">
<query>
<entrylist count="0">
</entrylist>
</query>
</response>
This message reliably makes the service code throw an EOleExecption.
"Good" message
<?xml version="1.0" encoding="Windows-1252"?>
<response space="" Message="Entry_7">
<query>
<entrylist count="2">
<entry>
<abc>123</abc>
<def>456</def>
</entry>
<entry>
<abc>789</abc>
<def>000</def>
</entry>
</entrylist>
</query>
</response>
This message is reliably processed without problems.
The problem first occured when moving the service from a Win2003 machine to a Win2008 (32-bit Standard).
