Notes from Tech Talk on Advanced .NET debugging with Windbg

28 Nov 2010
Have a comment or question? Please drop me an email or tweet me @ronnieholm.

My notes from a talk on Windbg by Brian Rasmussen which I attended this week. The talk was recorded and parts one and two are available though Channel 9.

  • Windbg isn’t a replacement for VS, but VS doesn’t handle some advanced cases
  • Windbg is a free user mode/kernel mode debugger which is part of the Debugger Tools for Windows
  • Customers may not be happy installing VS to debug code in production since it installs a lot of components and requires restarts
    • Windbg requires only a simple installation once you extract the redistributable from the Debugger Tools for Windows
  • Loading SOS.dll from the Microsoft .NET folder into Windbg makes it understand .NET
    • With SOS.dll loaded, you can look into the CLR and its data structures
    • Make sure to load the right SOS.dll for your runtime
    • SOS.dll is also available for the Silverlight runtime
  • Debugger Markup Language support is available for version 4 of SOS.dll
    • Provides hyperlinks in the command output of SOS
  • Like with the VS debugger, you can insert Debug.Break() in your demo app and have Windbg halt on it
    • Release builds can be debugged with Windbg
    • Release builds also contain symbols. Like with debug builds, symbols are stored in a separate file
    • Release builds make debugging harder because the jitter kicks in and modifies the code
    • The 64 bit calling convention of passing arguments via registers makes it harder to locate information when debugging
  • Windbg generally needs symbols loaded, although it’s less important when debugging managed code
    • Use MS’ public symbol server to load symbols on demand
    • Set the _NT_SYMBOL_PATH environment variable to point to your symbols (will affect VS as well)
    • Or use the .symfix command from within Windbg
  • Popular extensions to Windbg: SOSEX and Psscor2 (replacement for SOS, useful for ASP.NET debugging)
  • Create dump file to analyze: use task manager or ADPlus or ProcDump from Sysinternals, which can dump based on triggers
  • ADPlus collects crash dumps or hang dumps
    • Hang dumps can be captured from the same process multiple times and may be useful when debugging deadlocks or resource leaks
    • When you capture a hang dump, the process is halted for the dump period and is then restarted
  • A *32 process in task manager is actually a 64 bit process when you dump it
    • WoW64.dll is involved when dumping from the task manager
    • Not what you typically want because you don’t get full access to 32 bit process information
  • A .NET application is hosted within the CLR which is itself hosted within a regular Windows process
    • Looking at memory usage with the task manager therefore doesn’t tell you much about the .NET part