Debugging Hang/Crash Dumps

A very good article that can be used to debug hang or crash dumps.
http://www.infosysblogs.com/microsoft/2009/06/troubleshooting_wcf_service_ap.html

you may face certain issues while debugging.
Here is the link that helped me fix the issues that came across my debugging.
http://blogs.msdn.com/b/dougste/archive/2009/02/18/failed-to-load-data-access-dll-0x80004005-or-what-is-mscordacwks-dll.aspx

This will help identify memory leaks by type.
http://stackoverflow.com/questions/9016834/detect-wcf-channel-leaking-using-windbg


http://blogs.msdn.com/b/alikl/archive/2009/02/15/identifying-memory-leak-with-process-explorer-and-windbg.aspx?Redirected=true

To debug 32 bit dump on 64 box.
http://blogs.msdn.com/b/msdnforum/archive/2010/03/14/how-do-i-switch-to-32bit-mode-when-i-use-windbg-to-debug-a-dump-of-a-32bit-application-running-on-an-x64-machine.aspx

http://romikoderbynew.com/2011/05/07/memory-dump-analysisw3wp-iis-process/

Hang dump analysis.
http://codemachine.com/article_rpcchain.html

.load sos
!EEStack

to get full stack trace including managed thread. 

If issue loading sos dll then for  for 4.0 application
.loadby sos clr command should be used.

Follow this blog which has step by step information on how to debug a hang dump.
http://romikoderbynew.com/2011/05/07/memory-dump-analysisw3wp-iis-process/



Copy mscordacwks.dll, sos.dll and clr.dll from target machine and then copy it to your machine and run command
.load  "path of sosdll"
to get rid of sos version mismatch error.

To Load the symbols:

1. Load the dump file.
2. Run .symfix
3. Open the 'Symbol File Path' menu
4. Add a path to your application's .PDB files
5. Check the 'reload' checkbox
6. Run !clrstack -p to dump the stack with parameters.
7.