This reference tutorial will help you grasp the power of WinDebug debugging tool and quickly start using it in your daily development tasks. So, before we start, let me explain what WinDbg is.
WinDbg is a multipurpose debugger for Microsoft Windows, distributed on the web by Microsoft. It can be used to debug user mode applications, drivers, and the operating system itself in kernel mode. It is a GUI application, but has little in common with the more well-known, but less powerful, Visual Studio Debugger. WinDbg can be used for debugging kernel-mode memory dumps, created after what is commonly called the Blue Screen of Death which occurs when a bug check is issued. It can also be used to debug user-mode crash dumps. This is known as Post-mortem debugging.
WinDbg also has the ability to automatically load debugging symbol files (e.g., PDB files – Program DataBase file with debug information) from a server by matching various criteria (e.g., timestamp, CRC, single or multiprocessor version). This is a very helpful and time saving alternative to creating a symbol tree for a debugging target environment. If a private symbol server is configured, the symbols can be correlated with the source code for the binary. This eases the burden of debugging problems that have various versions of binaries installed on the debugging target by eliminating the need for finding and installing specific symbols version on the debug host. Microsoft has a public symbol server that has most of the public symbols for Windows 2000 and later versions of Windows (including service packs).
I’ve used WinDbg mostly in .NET applications, and that’s what I’ll be sharing this time around. To keep things simple and fast, because if you need WinDbg you are probably dealing with some memory issues and time is precious, I’ll put put it in steps:
1) You can start by downloading debugging tools from the Microsoft Windows SDK for Windows 7 and .NET Framework 4. You may also opt to download the ISO version. Take into consideration the target instruction set, either x84 or x64, depending on your application requirements.
2) Run WinDbg.exe executable. Search for WinDbg in "C:\Program Files (x86)\Debugging Tools for Windows (x86)" or “…WinDDK\7600.16385.1\Debuggers\windbg.exe” if you have the Windows Driver Development Kit.
3) Load mscorlib by writing:
> sxe ld:mscorlib
> g
NOTE: Press enter after each line. "g" continues debuger execution.
4) Load the SOS Debugging Extension (SOS.dll). This allows debugging of managed programs in the WinDbg.exe debugger and in Visual Studio by providing information about the internal common language runtime (CLR) environment. First command in example loads SOS for debugging framework 2.0. The second is used for Framework 4.0.
> .loadby sos mscorwks
> .loadby sos clr (Framework 4.0)
> g
5) Quick usage scenario #1: View memory consumption for all objects of a given type
> !DumpHeap -type MyAppRootNamespace.ViewModels.ClientProfileViewModel
6) Quick usage scenario #2: View the managed call stack
> !CLRStack
7) Quick usage scenario #3: View which object(s) are holding a reference to a specified address
> !gcroot 29682dc0
Here’s a little script you can use to detect Framework 4 and load it in WinDbg.
> !for_each_module .if(($sicmp( "@#ModuleName" , "mscorwks") = 0) ) {bp mscorwks!WKS::GCHeap::SuspendEE ".if (dwo(mscorwks!WKS::GCHeap::GcCondemnedGeneration)==2) {.echo start of gen 2}"} .elsif ($sicmp( "@#ModuleName" , "clr") = 0) {bp clr!WKS::GCHeap::SuspendEE ".if (dwo(clr!WKS::GCHeap::GcCondemnedGeneration)==2) {.echo start of gen 2}"}
Also, a full list of WinDbg commands, organized by category: http://windbg.info/doc/1-common-cmds.html.
And a PDF for you to print and keep it around your workspace.
Happy sessions.
