Windows Explored

One afternoon I had the luck of encountering a user who was experiencing random Outlook crashes while. As far as he was concerned, there didn’t seem to be any rhyme or reason to it. He would just be clicking through email messages and then, suddenly, he would encounter the following error (but not always): “Inbox – Microsoft Outlook: OUTLOOK.EXE – Application Error – The exception unknown software exception (0x…) occurred in the application at location 0x…“

Before getting to me, previous troubleshooting was undertaken by other technicians. This included disabling add-ins, recreating the Outlook profile, rebooting, starting Outlook in safe mode, and a bunch of other mythical hacks meant to remedy the unexplained¹. Nothing seemed to resolve the issue. Even the Windows Event Viewer was coming up with an unknown:

And, as mentioned earlier, sometimes Outlook would just quit, no error.

The first clue to the problem starts with the message above. It points to the Inbox, and I was betting that in the process of the user browsing his emails he was selecting a message that was causing Outlook to experience a fault that it could not recover from. I asked the user to start clicking through his messages, noting which message he was at when Outlook eventually crashed.

Since the crash was not being captured by the post mortem debugger for XP, Dr Watson, I needed to manually capture a dump. For this, I turned to Process Explorer to create a dump file of outlook.exe as it was crashing. Since the outlook.exe process was still running when the error was encountered (the process will remain running until you dismiss it by clicking OK to the error), this would be the quickest way to produce a dump for analysis². To do this, right-click the process and select Create Dump.

I copied the dumps to my workstation and opened them with WinDbg from the Windows Debugging Tools. Normally, I’ll run !analyze –v, but this can be a bit time consuming since we need to wait for symbols to resolve; I had the user on hold so I wanted to get a workaround for him as fast as possible. In a rush scenario like this, you can jump directly to the so-called current examine stack by using the k command:

Here we can get a quick glimpse of the stack. It’s short and sweet. There is an UnhandledException right after what looks like a 3rd party module. It’s name, OutlookAddin!DllGetClassObject, might initially fool you into thinking its an Outlook add-in, but running lmvm outlookaddin to reveals who this belongs to:

This module is part of our PDF Converter application, which includes a toolbar add-in for Outlook. The toolbar add-in itself cannot be disabled via Outlook Tools > Options > Other > Advanced Options > Add-In Manager. This explains why Outlook was crashing even in safe-mode. Outlook add-ins that continue to load while running in safe mode can have their load behavior modified in the registry. In Outlook, these settings can be found in HKLM\software\Microsoft\Office\Outlook\Addins\. To disable the problem module, I selected the PDFC5.OutlookAddin key and changed the load behavior from 3 to 2 (see load behavior values here).

After changing the load behavior and selecting the message, Outlook no longer crashed.

The question remained, though, what particular property of the message was causing this behavior when the add-in was enabled. To examine the message, I had the user attach it to a new email and send it off to me. After moving the attachment into the inbox, I was able to recreate the crash just by selecting it. The stack was slightly different but the culprit still reared it head:

To review the message later but keep it out of my inbox, I wanted to save a local copy of the message to examine outside of Outlook. This is when the odd property revealed itself: “Error Copying File or Folder – the filename or extension is too long.”

When you save an Outlook message locally, the subject line of the message defaults as the filename³. The max file name size cannot be more than 255 characters³. I opened the message and copied the subject line into Word to do a word count to see how many characters were in the subject line:

Even though Outlook can only display a maximum of 255 characters in the subject line for the message when it is opened or being previewed, it does actually display the entire subject line beyond 255 characters if you hover over the message subject while it is not in focus (or at least tries too). You can see below how the message expands across both my monitors and still does not fit:

I could see that the subject line was being populated by the content in the message body, specifically the abstract. Searching other messages from the same sender revealed that message subject lines were, in fact, being populated by content within the message body on a regular basis:

It’s not likely this is intentional but an unseen consequence of the manner in which the messages are being automatically created. This, combined with the presence of the 3rd party PDF module, was leading to a unique condition that caused Outlook to crash. The issue was (or had become) much more widespread than I thought; many of our attorneys receive these messages from ddsmail@wcsrcmf.com on a frequent basis, which often generated calls to the help desk that went unexplained. In later encounters, I also saw that SPAM messages could also contain abnormal subject lengths, leading to the Outlook crashing in the same manner with the presence of the add-in.

¹In later encounters, technicians were scheduling to have the user’s entire Windows profile recreated in attempts to resolve; a step that, too, would have failed to resolve.

²You can, of course, set WinDbg as your default debugger and break right into the crashing process immediately. But this is not practical for a spot issue on user’s workstation.

³Windows will remove the invalid characters from the subject before it goes into the filename, e.g. commas.

⁴A fully qualified file name is comprised of both name and file path, which factor into whether the file can be saved with its current name.