Occasionally, it is necessary to integrate a software package that just isn’t working, and no support is available. For instance, the version might be so old that the development company no longer support it, yet the software is still a critical part of the client’s IT infrastructure. Without the source code, and only a cryptic error message or random failure for guidance, how do we solve the problem?
To the rescue comes ProcMon, one of the most effective software analysis tools since debuggers. ProcMon logs every important application-level Windows operation: reads/writes to the disk, reads/writes to the registry, and network activity. By analyzing the application as a “black box”, the root of the problem can often be diagnosed and fixed.
I recently faced a software challenge with an X-ray analysis software that crashed upon startup on some machines after installation of a software update. Some client machines would run well, while others would crash immediately upon program start.
The first step to diagnosing such an issue is to start ProcMon, begin a trace, and start recording the Windows operations. Since the software captures every Windows event, it will log hundreds of thousands of operations before the target application even starts. Take advantage of this by selecting the option “Drop Filtered Events” and right-click on each unrelated process name and select “ignore.” Once no new events pop up in the window, we are ready to begin.
Start the target application and run the software until the problem occurs. At that point, stop capturing events and save the log. This should create a fallback point so that the entire logging operation does not need to be repeated in case the filters need to be reconfigured.
It’s often helpful to slice the data two different ways: first by viewing the full log, and if that proves inconclusive, afterwards filtering out any successful events and only displayed failures. It’s a common misconception that the failures in ProcMon are bad – actually every application will generate thousands of failures due to the nature of DLLs. Every time most software starts, it will run thousands of excess operations in trying to locate shared files necessary to run the program. The real challenge is to parse all the failures, and find the true failure that is causing the crash.
Once this failure is identified, it’s time to fix the issue. If a DLL is missing, a quick prerequisite install is sometimes all it takes. In the instance of the integrated X-ray software, an older version conflicted with the upgrade, and it was necessary to modify registry settings to get everything working. This step often requires experience and intuition, however stubbornness and guesswork can do the job as well.
With ProcMon, problems that were previously virtually impossible to fix can be diagnosed in less than an hour. The Swiss-Army knife of application debugging, it is an indispensable tool once all the primary avenues of software debugging have been exhausted.
Written by Andrew Palczewski
About the Author
Andrew Palczewski is CEO of apHarmony, a Chicago software development company. He holds a Master's degree in Computer Engineering from the University of Illinois at Urbana-Champaign and has over ten years' experience in managing development of software projects.
Google+
Reading book review is engouh to have an idea about how the book is like and also whether to purchase it or not. In traditional book stores it is not an easy task to search for the book one wants. district judge colleagues in San Antonio that he plans to take senior status and move. Furgeson was appointed to the federal bench in 1994 by then-President Bill Clinton.