Windows Explored

It’s not uncommon for outdated drivers to have a negative impact on user applications. Without knowing how to do some basic crash analysis, finding an outdated problem driver can be quite daunting when you consider how many drivers there are on the average system. However, you can simplify this by looking for or obtaining a crash dump of the application.

In the case here, we have a user complaining of frequent crashes while working in Adobe Photoshop. This is an XP system so I am hoping that Dr Watson, the default post mortem debugger*, is capturing the crash. I ask for the computer name and UNC to the location where the drwtsn32.log and user.dmp files are written when an exception is caught; this can be found in \Documents and Settings\All Users\Application Data\Microsoft\Dr Watson. Both files are there and have a recent modify date-time, and I copy both of these to my system for analysis.

Because Photoshop is primarily graphics, I am guessing we might find a graphics driver somewhere in either file along with an exception. I start by opening the drwtsn32.log, a plain text file that records a history of all the crashes it captured. The file is read from the bottom since this is where the latest information is added. From there, I do a text search going up for the word application to verify that Photoshop is the crashing application:

From here, I search down for FAULT (check the Match Case option) and take a quick look at the Stack text, looking for any 3rd party components:

Nothing 3rd party here; these are Microsoft components. I will need to look at the user.dmp with WinDbg from the Windows Debugging Tools and examine other threads in the dump, looking for (literally) an exception. After opening, I dump all the threads with ~*k and start working my way up until I find what I am looking for:

UnhandledExceptionFilter and KiUserExceptionDispatcher are the tell tale signs that this is our problem thread. You read the stack going up. You can see before the exception is reached a module called ialmgicd appears. Examining using the lmvm command tells us where it is but not what it is. We will need to go look in the path to get further details or search for the name of the file on the Internet. Our search shows that this file is, in fact, an Intel graphics driver file. From the output of lmvm you can see the driver is 6 years old and likely an update exists so this would be our first approach to resolving the crash.

*Windows Vista/7 do not come included with a default post-mortem debugger out of the box. You need to go into the registry to change this behavior; see here. Otherwise, do not dismiss the error when the application crashes and use Task Manager to dump or debug the process.