Windows Explored

While trying to import documents into our document management system via Outlook, Outlook would just abruptly close on the user. I started the initial troubleshooting by disabling a couple 3rd party add-ins in HKLM and HKCU\Software\Microsoft\Office\Outlook\Addins that were not part of the normal image. This can be done by modifying the load behavior of the add-in (see this MSDN article for details), but this had no effect on correcting the behavior. I thought about capturing a crash dump of Outlook but decided to not waste any time there because, at this point, with the add-ins disabled, I likely was not going to see anything but the document management modules in the dump.

Instead, I turned to Process Monitor; perhaps it might reveal what Outlook was doing just before it crashed and give me some important clues. I set a filter to monitor only outlook.exe, dragged an item into the document management space in Outlook and waited for it to crash after clicking Save. Afterwards, I scrolled to end of the log, working my way up. I also added a filter to only include registry activity and then process and thread activity so I could quickly see where Outlook was crashing:

(You might notice that when applications fail to exit gracefully that the Exit Status will be a number other than 0, which would otherwise indicate a normal close)

I can’t say the above registry key (AutoCompleteEx\5308\FolderLookup) means anything to me, but I can look inside it to try a figure out its purpose. In the case of the user, this key was big … 3500+ string values big. I connected to a lab PC, deleted the key there and imported an item into the document management system. I could see from this action that the string being written to this key seems to be a simple import data, which lists the document management server and folder path where the item is imported to, e.g. !nrtdms:0:!session:XXX-DMS1:!databaseXXX:!folder:ordinary,7623:<TO BE FILED <999910.000040>.

The user in this case spends much of his time importing items into the DMS, which explains why the key was so big. To see if the key was truly the problem (or part of the problem) I imported the registry key under suspicion to a lab PC and was able to reproduce the crashes. Furthermore, I could see that in the few cases where an import did not crash Outlook that this key did not contain the new data string for the successful import. To test a solution, I simply deleted the FolderLookup key, which would be recreated upon the next import into the DMS, imported several items multiple times, and Outlook was no longer crashing. Perhaps there is some undocumented limit to the size the key can grow before it starts misbehaving or a yet undiscovered bug.