Post-mortem debugging of .NET applications using WinDbg
Debugging is a skill you usually learn under pressure, when things are going awry with an application or service just gone live. It is never a pleasure to encounter such bugs because, although they happen quite frequently in your production environment, they are particularly hard to reproduce in your test environment.
For managed applications, you can learn a new skill that will save you some face, called post-mortem debugging. WinDbg is a splendid tool that is often used to debug running processes, but can also be used to analyze process crash dumps.
Dump process memory
Process memory can be dumped quite easily.
Right click on a process and select Create dump file.
Attach to a process and dump memory from the File menu, or the command line
.dump /ma filename.dmp
You need to have enough disk space because
dmp files can be rather big.
There are more ways documented elsewhere, but the above should suffice for most purposes.
Once you have the crash dump file, you can open it with WinDbg, and examine it with several useful commands
Shows thread times. This can be really useful to find badly behaved threads that are consuming a lot of CPU.
Shows detailed information about the current exception.
Shows a list of threads currently in execution.
Displays all stacks of all the threads of the current process. You can also see the stack trace of a single thread using the
Sets the thread with ID
nas the current thread.
WinDbg is most useful for debugging managed application using the following extensions
This extension is distributed along with the .NET framework can be loaded using the following command:
.loadby sos mscorwksor
.loadby sos clrfor .NET 4.
This has several useful additions to the core SOS extension. It must be loaded using the
Has several useful commands, especially commands for debugging ASP.NET applications. Load it using the
The SOS extension has several useful commands, particularly
Prints the stack trace of the current thread. This only works for managed threads. If you have symbols for your assemblies, you can see some pretty useful information in the stack trace.
Dumps the objects from the heap. You can dump objects of a specific type by using the
!dumpheap -type System.Threading.Thread. This can be really useful to list all objects and their addresses. By knowing the number of objects of a particular type in use, you can debug resource exhaustion problems.
Dumps information about the object at the address specified. Value of primitive fields of the object are displayed and other references can be further examined using this command.
Prints information about an array
The SOSEX extension has the following commands that are particularly useful
Prints all objects that reference the object specified.
Searches for possible deadlocks.
The Psscor2 extension has one particularly useful command, among several others, that can come in handy when troubleshooting network related issues
Prints the IP address of the specified IPAddress instance.
This short post is meant to whet your appetite for post-mortem debugging and to point you in the right direction.