Wednesday, November 01, 2006

Debug Tools for Windows - Snapping a Process

This is a modified email that went out to our development and operation teams yesterday that I thought I'd share.

The focus of the post is help educate our operators and administrators on what to do when they witness behavior in a production system that needs to be reviewed.

In this particular case, memory utilization of a process grows until the process stops responding, which affects our user base, which is when the phone starts ringing! To keep things 'moving along' the process is typically recycled.

During the pressure of attempting to right a system thats gone belly up, we want the it to become second nature to inject an additional step in the current process which will aid in diagnosing the problem.

Installing Debug Tools for Windows


The latest version can be found here. Check your servers to make sure they have a recent version! Recent being defined as a version that was released this year.

I’ve installed this on production servers without problems. One thing to note, there are two ways to get it ‘installed’ on the server in our environments.

  1. Run the installation by clicking the setup.exe - or -
  2. Run the installation on one server and then xcopy the directory to the production server. The only thing you lose is access to the tools from the Start menu. This is how the server team typically installs it on c:\tools\deugging tools for windows. You’ll note that the version on the servers is likely out of date unless you’ve installed/upgraded it yourself.


To take a memory snap
(sometimes referred to as a ‘dump’; ‘snap’ just sounds better):

  1. Open a command prompt
  2. Change to the Debugging Tools for Windows directory
  3. Execute adplus –hang –p xxxx (where xxxx is the process id of the process you want to snap); an option you may need is the ‘-o’ which is to redirect the dump to a directory other than the current working directory.

In the default configuration, meaning you’ve installed per procedure above, you will receive a warning dialog about missing environment variable symbol paths. It’s safe to ignore this dialog.

If it’s suspected that a process is ‘hung’, or ‘locked’, take additional snaps of the process, but at least a minute apart. Usually 2-3 will suffice. This will allow the reviewer to confirm a hung process or not.

A snap will take up as much memory on disk as the process consumes, so it can fill a disk quickly. Because the threads of the process are temporarily suspended during a snap, I do not recommend pointing the output (-o) to a file share when you actually take the snap. This adds much latency to the operation. It’s much faster, and less intrusive, to snap it to a local disk and then xcopy to a network share, or a workstation for review.

There are additional options, all of which are available from adplus.vbs; just open it up in your favorite text editor for review. There is also a significant amount of information online, just try Googling ‘adplus’, ‘debugging windows’, etc.

1 comment:

  1. Anonymous1:00 PM

    Hi, my name is Jeff with the Microsoft CPR (Critical problem resolution team), Nice post. I thought I would share some of the work we are doing with hang collection. If you want to automaticly detect hung window we put a sample on our blog that shows how it can be done. In addition we have a series of LABs with detailed training that shows you have to debug the dumps without source.
    Visit the advanced windows debugging blog at http://blogs.msdn.com/ntdebugging.
    Our hang blog Is here http://blogs.msdn.com/ntdebugging/archive/2007/05/29/detecting-and-automatically-dumping-hung-gui-based-windows-applications.aspx

    And our Hung Window?, No source?, No problem!! Part 1 blog is here.

    http://blogs.msdn.com/ntdebugging/archive/2007/06/13/hung-window-no-source-no-problem-part-1.aspx

    Part 2 is located.

    http://blogs.msdn.com/ntdebugging/archive/2007/06/15/hung-window-no-source-no-problem-part-2.aspx

    Thank you.

    Jeff, Microsoft CPR.

    ReplyDelete