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