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