I'm posting some notes from my latest debugging adventure.
The big advantage to WinDbg is easy deployment on a test machine. I don't have to worry about installing remote debugging with visual studio or correctly setting up the permissions.
The notes:
1) Although the download site says that you probably want to run 64 bit WinDbg on a 64 bit machine, the machine architecture is irrelevant. Most apps that I've been writing, and especially those that use legacy COM objects are x86 and WinDbg behaves poorly if you don't get the right version for your architecture. The download page is
here.
2) Downloading WinDbg is still annoying. But this is only because I remember the good old days where I only needed to download the Debugging Tools for Windows and not some entire SDK.
3)
sxe clr
This breaks the debugger whenever there is a CLR exception. I'm always after some .net bug. This is the first thing that I type in to get going, usually right after WinDbg attaches.
4) .
loadby sos mscorwks
This loads the SoS Debugging extensions for .net. I wait until WinDbg breaks after the first CLR error, because this command won't work until mscorwks is actually loaded by the program.
5)
!pe
This is short for !PrintException. It outputs information about a .net exception.
6)
!CLRStack
This outputs the .net stack trace, ignoring the surrounding native code.
7)
!dso
Dump Stack Objects. Helps you figure out what objects in memory are likely to be involved in any current problem.
8)
!do
Dump Object. Information about a single object.
A cheatsheet
