Dumping A Thread to Find An Exception
Posted by William Diaz on August 3, 2011
Before any basic crash analysis, I always turn to the Windows Event view to find signs of problem. In the case here, the problem manifested itself as Outlook crashing when the user opened a particular Outlook form. Looking at the Windows Event Viewer, we see an application event for Outlook:
The faulting module is fm20.dll. To get an idea of what this dll is for I search for it and look at its properties:
This makes sense since we are loading an Outlook form.
Before capturing a dump, I usually will do a couple basic troubleshooting steps. I started Outlook in safe mode and opened the form. Outlook did not crash. So the problem seems to reside with one of the add-ins that were disabled by safe mode. We have several add-ins for Outlook. These can be disabled from Outlook directly one by one until the issue disappears*. This can become a bit tiresome–disable an addin, start Outlook, open the form, crash Outlook, lather, rinse, repeat.
Instead, I decided to get a dump of Outlook as it crashed. Since this was a user’s workstation, I installed Microsoft Debug Diagnostics and created a rule to create a dump when Outlook crashed. Afterwards, I copied the .dmp file to my desktop and opened with WinDbg from the Windows Debugging Tools.
The !analyze –v command confirmed the event I saw in the Windows Event Viewer above:
We already confirmed by opening Outlook in safe mode that it was not a problem with the module. We are most likely looking for some 3rd party component but the stack text reveals nothing other than Windows and Office out-of-the-box components.
If !analyze –v heuristics fails to reveal anything interesting, I normally start by going off and looking for an exception, literally. A good way to start when you do not have an advanced or expert grasp of WinDbg (like me) is to go to the View menu and open the Processes and Threads and Call Stack windows and start going through each thread until you find an exception, which could be in the form of RaiseException or UnhandledException; Error and Fault are other key words to look for as is MessageBox if you happen to encounter a message from the crashing process. I lay both these windows side by side and start by selecting each thread and looking for the term in the adjacent window, like in the image below.
But just looking at the stacks in each thread did not turn up anything. I would need to dig deeper. I am assuming that the current examine thread, thread 0, is where the problem arises so I want to examine the block of memory addresses in this thread (to change to a different thread, use ~0s, where 0 is the number of the thread you want to look at). I use the !teb command (thread environment block) to expose the starting and ending memory address range of this thread:
I want to look inside the memory address range above. To do this, I use the dds command plus the starting and ending address range, i.e. dds 00135000 00140000, to dump the thread. The output is rather long so I will need to search going up for our exception using Ctrl+F:
At this point, I use dds again to look into the address space of KiUserRaiseExceptionDispatcher, 7c90e4a5, to obtain a clue to the Outlook’s form woes:
If you are not sure what the module is, use the lmvm modulename to look at its properties:
To test this finding, I went into Outlook and disabled the extension in Outlook for the document management system this module is associated with, opened the problem Outlook form and the crashes no longer occurred. From here, the next logical approach would be to uninstall the add-in and re-install.
Annoyingly, the issue remained even after reinstalling. I am not sure, but this may have been caused by the add-in views in Outlook. The removal and install process was likely not overwriting some of these user specific files or registry settings that are created by the user as they modify certain views within the add-in in Outlook. The actual solution was to open the form outside of Outlook, modify the view by resizing or going full screen, and closing to save that view setting.
The important thing gained was that, even with a minimal understanding of WinDbg, I was able to find an exception by dumping the suspect thread. From start to end, including installing Debug Diagnostics on the user workstation, it took less than 10 minutes to isolate the potential cause.
*Other add-ins need to be disabled by modifying the load behavior in registry, usually from HKLM or HKCU\Software\Microsoft\Office\Outlook\Addins, otherwise their load behavior negates running Outlook in true safe mode.
Windows Explored 
Leave a Reply