Using Process Monitor for software error investigation
I’m not typically involved in the support for the software that the company that I work for produces but this morning I was asked to consult on a problem that was affecting the application support team here. Fortunately there are no reports that the client we produced this exact piece of software for is experiencing the same error.
I was asked to consult because the error appeared to be due a change in the IT infrastructure in some way as it was affecting multiple people and the code itself had not been changed by the developers. The error is in a software module that is supposed to produce a document from a set of data that is being currently viewed however it just throws up an error message. Because it was apparently working earlier this week, nothing has changed in our code and we had a Patch Tuesday this week could a Microsoft Windows update be the underlying cause of the error?
The first thing to do was to understand exactly what was going on and what processes were failing. The error message itself was useless and nothing was getting logged in the Windows event logs so what was needed was a tool to capture data on running processes.
Sysinternals Process Monitor is just the tool for the job and no SysAdmin worth his salt will have not had call to use it many times in their career. Process Monitor is a fantastic tool but can be a little intimidating at first as it generates a huge amount of data which seems like it would take hours to analyse a minute’s worth of captured events.
However there are a couple of simple little things to do to drastically cut down on the amount of data to sift through.
- Exclude processes that are probably not relevant to the error. Do this by right-clicking on a process in the window and selecting the appropriate option from the menu.
- Clear the display just prior to running the program or performing the task that causes the error you want to investigate and then stop the capture of events once the error has occurred.
So I excluded explorer.exe and then svchost.exe and spoolsv.exe. This cut the list down massively then I also excluded a couple of processes associated with the AVG antivirus and also Microsoft Word and Excel. Cleared the display, started the capture, forced the error to happen again and then stopped the capture.
It then just took under a minute to find the failing process from amongst the few hundred logged events. An ActiveX control that is referenced by the software in order to produce the document could not be found. I then ran the whole thing again on a different machine that had not yet been patched, a slight security risk but necessary in a software development environment in case there are ever conflicts with a new Windows update. The error occurred on this computer also so I was able to rule out a relation to Patch Tuesday.
At this point my job was done (at least for now). I had pinpointed the ActiveX control that was causing the error and had ruled out Windows Updates as a cause. The issue is now being investigated by the software developer that wrote the code.