Tips for successful .NET Debugging with WinDBG

Here are my tips for pain free .NET debugging with WinDBG

1) Always use a 32-bit debugger for a 32-bit process and a 64-bit debugger for a 64-bit process, both to generate the dump and to analyse it. Use usermode dumps only (managed debugger extensions are not expected to work with kernel mode) and ensure the dump is generated with full memory and debug streams (.dump /ma )

2) Check that the correct, matching symbol for the CLR has been loaded (mscorwks.dll for 2.0 and clr.dll for 4.0) (use lmvmmscorwks or lmvmclr to check, watch out for # or M or C symbol that might indicate a mismatch

3) Load the correct extension (PSSCOR2 for 2.0 and PSSCOR4 for 4.0) and then issue a command like !threads just to verify that managed debugging is working

4) If step 3 gives you an error if may be that the debugger is unable to find the correct Data Access Component (DAC) for that version of the CLR. The DAC gets installed with each version of the CLR as mscordacwks.dll so you can always get it from the same machine where the dump came from. Copy the appropriate one (or all of them) into the same directory as WinDBG.exe maintaining the naming convention mscordacwks_xPP_xPP_2.0.50727.vvvv.dll. A blog posting discussing this more can be found here.

5) If you are trying to figure out what version of the CLR you are dealing with look at the version number using lmvmmscorwks or lmvmclr and cross reference to the CLR 2.0 version history or CLR 4.0 version history.

6) Another really important and powerful debugger extension for managed code is SOSEX.