Windows Explored

When trying to view one of the regular emails sent out daily within the firm, users who enabled the preview pane were encountering the following information bar in Outlook: “This item cannot be displayed in the Reading Pane. Open the item to read its contents.”

Then upon trying to open the message, the following error was encountered: “Can’t open this item. Out of memory or system resources. Close some windows or programs and try again.”

This had nothing to do with a lack of system resources. It also happened across different versions of Outlook (2003 and 2010). The message itself does not contain any out-of-the-ordinary properties at first glance. It is formatted as RTF so there is no hidden formatting that you might otherwise encounter in an html formatted message. Later, a co-worker who was also getting complaints about the same issue, examined the Internet Headers of the message and noted a very large thread-index, one that went on for hundreds of lines, but she wasn’t sure what it meant. The example below is just a portion of the thread-index for the problem message:

A normal Thread-Index with a few replies will look like this:

I raised the finding with one of our Exchange admins, which left him scratching his head. Curious myself, I did a little research. Think of a thread-index like a conversation history of the message. The thread-index is expected to grow, normally when the message is forwarded or replied to. There doesn’t seem to be any official documentation, but from what I have been able to gather, the thread-index starts out as 22 bytes and each reply or forward adds the original thread-index + 5 more bytes, for 27 bytes (encoded as Base64). Another reply would then add another 5 bytes plus the previous 27 byte thread-index, and giving us a new thread-index of 32 bytes, and so on.

In the case here, our user(s) are “recycling” or using the previous day’s message as a template to create the new email message each time by forwarding it, removing visual FW cues, removing the message body and replacing it with new information. This is usually done once or twice a day, and probably for the better part of a year or more, which explains why the thread-index had become so big.

I assume that there is some internal message property that is being exceeded and generating the error message above. To see what message property that is, I turn to OutlookSpy. It doesn’t matter that I can’t open the message*, I just need to select it in the message pane and then select IMessage. The thread-index in the Internet Headers seems to relate to a property known as PR_CONVERATION_INDEX, and you can see that its value is equal to MAPI_E_NOT_ENOUGH_MEMORY (which generates the error dialog encountered):

There seems to be a hard limit to the size the PR_CONVERATION_INDEX can grow (32 KBs?) and the process of forwarding the message over and over and over again created a conversation index that exceeded this limit. To test this, I deleted the PR_CONVERSATION_INDEX property and was then able to view the message normally. Actually, you can also recreate this problem with any Outlook-Exchange message by populating the data in the PR_CONVERATION_INDEX property with large a large amount of gibberish.

In the end, the fix was a simple matter of creating a new message. Of course, since this is somewhat the culture of the group that puts together these specific messages, I expect them to continue doing this again and, perhaps a year from now, the problem will once again be encountered. Ideally, an Outlook form may be the best approach here if it is too much of a hassle to create a new message each time.

*A small group of users, myself included, were not affected. I narrowed this down to not being in Exchange cached mode. To reproduce, I put myself in cached mode and encountered the problem. As a temporary solution, user’s who were not able to open the message could workaround this by dragging it from Outlook to the desktop and opening it from there (instead of being removed from cached mode). Why a cached mailbox exhibits this behavior and an “online” exchange mailbox does not, I have not been able to figure out.