This tool
is one of the smartest tools around and comes with an extensive help file. It
has a very intuitive GUI and can assist you in troubleshooting hang, crash,
deadlock, slow performance or memory leak and fragmentation. It contains a lot
of nifty, ready-made scripts which you can use to diagnose your memory dump
with.
So… what is a memory dump?
A memory dump is a kind of snapshot of a process and
contains useful data at the time you created that snapshot. It can tell you a
lot of things, like which pages are being executed by the process, how many of
them are waiting, what are the kinds of objects allocated, etc. Say you are
facing any of Problems 3, 4 or 5 stated in the beginning of the article. You
can create memory dumps at times when you see the bad performance and get it
automatically analyzed by Debug Diagnostic tool. In fact, even if you are
seeing Crashes (Problem 1 and 2), you can use this tool to find out what is
crashing your process and fix the issue, which could be very difficult to fix if
you do not have a memory dump. In fact, the problem is how you will actually
figure out if you are seeing crash related issues on your server. I have
blogged about it in the past and hopefully that
post should help you to some extent.
How can you create a memory dump for any process using
Debug Diagnostic tool?
Start your debug diagnostic tool.
Click on the Cancel button on the wizard that you get by
default.
Click on the Tools menu, select Create IIS/COM+ Hang Dump
and choose Yes on the message box that pops up.
Figure 3
It will create the dumps and will show an appropriate
message box to you.
Figure 4
If you look at the folder mentioned above, you will see two
.DMP files (in your case it could be more if you have a lot of application
pools) and those are your Memory dumps.
If you want to take dump of a specific process, Debug
Diagnostic can help you there as well. Just switch to the Processes tab and you
will see the list of all the processes.
Figure 5
Right click on any process, select Create Full User dump and
you are done!
It is not a good practice to take one dump, analyze it and
tell anyone… that it is okay. Here is the problem. Normally, it does not happen
that way and has a good chance of misleading you. If you want to be sure of the
issue, you should take multiple dumps about 3-4 minutes apart (if you are
seeing slow performance) and analyze them to see if you find the same issue in
all of them.
Learning to analyze memory dumps has a steep learning curve
and although Debug Diagnostic will do the basic analysis for you, it might not
be the PERFECT analysis simply because it is based on some scripts. It is a
very good tool, but is by no means the only tool you need to have to fix all
your performance issues!!! That said, you cannot write it off, since it is good
enough to guide you and sometimes it is bang on target. Go through the help
file. It is pretty neat and littered with appropriate pictures throughout.
How can you analyze a memory dump using Debug
Diagnostic tool?
Once again, the help file is pretty detailed. Navigate to
the following location and read through Advanced Analysis.
Figure 6
NOTE: While collecting the dumps, ensure that Perfmon has
been logging the data for a while. Basically, a good practice is to ensure that
Perfmon logging is enabled and you take at least 3 dumps about 3-4 minutes
apart and THEN stop the Perfmon logging.