Copyrights @ Journal 2014 - Designed By Templateism - SEO Plugin by MyBloggerLab

Friday, February 27, 2004

Analysing Windows Hang or Crash Dumps

Analyzing Windows Hang Dumps
All we know is how to analysing the Windows Dumps, they provide all valuable information about how to analyse, what happened in Windows memory that moment. This gives out all the information we need for finding out the cause behind the problems.
Once those dumps are made you can analyze all the threads and also the objects running in memory. You can grab along the hang dump, the application dlls loaded in memory.

There is a lot of interesting information all over internet. Most of them talk about working with old VS 6 version of MS code. There are hardly any websites which talk about the .NET CLR debugging except
"Production Debugging for .NET Framework Applications "
"SOS Debugging of the CLR, Part 1"
They are the ones who talk about the debugging, the first one is way more deep.

Get the Debug Tools for Windows, just download and install.
Most important thing in analysing those is to get the symbols. Symbols for you application files is easiest to get. Otherwise you have to search on Microsoft site for the CLR symbols. There is facility by which you can set up an environmental path "_NT_SYMBOL_PATH", set it to value like "SRV*c:\symbols\web*; c:\symbols\app;c:\symbols\os;C:\SYMBOLS\SOS". This is the first thing you want to do. It has few more details involved.

"SRV*c:\symbols\web*" - Tell WinDBG to download the Operating system symbols to download, and where to download and from where.

You can download the symbols on you own and keep it on hard drive, they are available at DDK website of Microsoft. Beware to download the symbols you want. Gather the symbols for your application too.

Then most important thing you want to do it to get then is .NET CLR symbols. We need those if you have to get the .NET stuff debugged properly. There are symbols for the MSCORSVR.dll and MSCORWKS.dll. They form the major part of the .NET framework. These dlls are the available from Microsoft here. They attach the standard 1.0 dlls. I am not sure how you get those, symbol files for 1.1. I didn't get them at all. If somebody knows please let me know more about them. You would be surprised they are for the Framework versions as 1.0.3705. 0, 1.0.3705. 209, 1.0.3705.288 and 1.3705.0.352 only. The documentation for SOS usage is available in Framework SDK 1.1 at path "SDK\v1.1\Tool Developers Guide\Samples\sos". You can get the code also for the same from SSLI, download here.
Note that the base version is for 1.0.3705.0 , then the service packs or hot fixes change the version of the framework, though they all are under the 1.0 framework. There is a KB article on MS TechNet which describes how to determine the version of framework you are running. I would suggest not to use that as it just looks for the version of MSCORCFG.dll and NOT MSCORLIB.dll, MSCORSVR.dll and MSCORWKS.dll. The other three assmblies actually form the basic framework. The service packs or the other hot fixes upgrade the version of these dlls but the MSCORCFG.dll remains at base version. So it is kind of unreliable. So I just checked the version of those dlls to confirm. If you have other versions than those, god help you I could not find the BIN files for those.
Then you have to load the psscor.dll and then make a command as !findtable provide it path for you .Net SOS symbol BIN files (C:\symbols\sos may be). If this runs good, you have all setup for running the debug mode. The psscor.dll is only for asp_wp process. You might need to find more for all other if you are using something else.

There is set of command you can use for accessing and then finding out more about the WinDbg tool. Run the command as !help on command prompt in the WinDbg you should be able to get all te SOS commands list. I really wanted to publish the list of commands but still I have digged into them that hard. Just learning!!!

The !dumpMT and !dumpModule allow more insight on the Method table and also the modules loaded in the memory. There is still lot to be found in great details. There are some basic commands for the finding out more about the threads and thread pools, they not exactly for managed code.

I need to read more on the managed thread pools. They also provide valuable information on the memory dump analysis. The '!dumpallexceptions' command after loading the psscor, will dump all the unique exceptions in the memory. This will also list the count of the exceptions listed. The '!thread' command provides the context, state, exception, GC, domain and thread locks. The 'Production Debugging' article link in the top has a whole section written for how to set the breakpoints and deep debugging techniques for the thread contention problems.

Note: Update 01/30/2006 If you are debugging, .Net Framework 2.0 or 1.1.4322, use the SOS.dll from the one provided with framework. For more information you can check this site.