Click here to Skip to main content
15,860,859 members
Articles / Desktop Programming / MFC

Windows Debuggers: Part 1: A WinDbg Tutorial

Rate me:
Please Sign up or sign in to vote.
4.91/5 (133 votes)
22 Mar 200416 min read 1.6M   10.8K   555   86
This is the first part of a multipart tutorial on debugging using WinDbg.

Table of contents

Introduction

In my professional career, I have seen most of us use Visual Studio for debugging but not many of the other debuggers that come for free. You may want such a debugger for many reasons, for example, on your home PC which you do not use for development but on which a certain program crashes from time to time. From the stack dump, you can figure out if IE crashed because of a third party plug-in.

I did not find any good quick starters for WinDbg. This article discusses WinDbg with examples. I assume you know the basic concepts of debugging – stepping in, stepping out, breakpoints and what it means to do remote debugging.

Note that this is meant to be a Getting Started document, which you can read and start using WinDbg. To know more about specific commands, consult the WinDbg documentation. You can use the commands presented in this document with any debugger provided by Microsoft, e.g. from the Command window of Visual Studio .NET.

This article is based on WinDbg 6.3.

This is the first of a series of articles on debugging. In my next article, I shall explain how to write debugger extension DLLs.

Overview of Debuggers

A brief overview of the Windows debuggers that you can download for free from here:

  • KD – Kernel debugger. You want to use this to remote debug OS problems like blue screens. You want it if you develop device drivers.
  • CDB – Command-line debugger. This is a console application.
  • NTSD – NT debugger. This is a user-mode debugger that you can use to debug your user-mode applications. Effectively, this is Windows-style UI added to CDB.
  • Windbg – wraps KD and NTSD with a decent UI. WinDbg can function both as a kernel-mode and user-mode debugger.
  • Visual Studio, Visual Studio .NET – use the same debugging engine as KD and NTSD and offer richer UI than WinDbg for debugging purposes.

Comparison of Debuggers

FeatureKDNTSDWinDbgVisual Studio .NET
     
Kernel-mode debuggingYNYN
User-mode debugging YYY
Unmanaged debuggingYYYY
Managed debugging YYY
Remote debuggingYYYY
Attach to processYYYY
Detach from process in Win2K and XPYYYY
SQL debuggingNNNY

WinDbg

WinDbg is a debugger that wraps NTSD and KD with a better UI. It provides command-line options like starting minimized (-m), attach to a process by pid (-p) and auto-open crash files (-z). It supports three types of commands:

  • regular commands (e.g.: k). The regular commands are to debug processes.
  • dot commands (e.g.: .sympath). The dot commands are to control the debugger.
  • extension commands (e.g.: !handle) – these are custom commands that you can add to WinDbg; they are implemented as exported functions in extension DLLs.

PDB files

PDB files are program database files generated by the linker. Private PDB files contain information about private and public symbols, source lines, types, locals and globals. Public PDB files do not contain types, local and source line information.

Debugging Scenarios

Remote Debugging

Doing remote debugging using WinDbg is easy and can be done in one of a number of ways. In the following, ‘debugging server’ is the debugger running on the machine where you’d like to debug; ‘debugging client’ is the debugger controlling the session.

  • Using the debugger: You need CDB, NTSD or WinDbg on the server. A WinDbg client can connect to any of CDB, NTSD and WinDbg, and vice versa. The server and client have choices of TCP and named pipes for communication protocol.
    • To start a server:
      • WinDbg –server npipe:pipe=pipename (note: multiple clients can connect), or
      • from within WinDbg: .server npipe:pipe=pipename (note: single client can connect)

      You can start multiple server sessions using multiple protocols. You can password-protect a session.

    • To connect from a client:
      • WinDbg -remote npipe:server=Server, pipe=PipeName[,password=Password]
      • from within WinDbg: File->Connect to Remote Session: for connection string, enter npipe:server=Server, pipe=PipeName [,password=Password]
  • Using remote.exe: remote.exe uses named pipes for communicating. If you use a console-based application like KD, CDB or NTSD, you could use remote.exe to do remote debugging. Note: use @q (not q) to quit the client without quitting the server.
    • To start a server:
      • Remote.exe /s “cdb –p <pid>” test1
    • To connect from a client:
      • Remote.exe /c <machinename> test1

    test1 above is the arbitrary named pipe name we chose.

Server will display who all are connected from which servers and commands executed. You can quit the server by issuing ‘qq’; or quit the client using File->Exit. You’d need to belong to the “Debugger Users” user group and the server has to allow remote connectivity if you want to remote-debug.

Just-in-time Debugging

The section “Enabling Postmortem Debugging” in the WinDbg documentation discusses this well. In short, you can set WinDbg as the default JIT debugger by running Windbg –I. This sets the registry key HKLM\Software\Microsoft\Windows NT\CurrentVersion\AeDebug to WinDbg. To set WinDbg as the default managed debugger, you’d need to set these registry keys explicitly:

  • HKLM\Software\Microsoft\.NETFramework\DbgJITDebugLaunchSetting to 2
  • HKLM\Software\Microsoft\.NETFramework\DbgManagedDebugger to Windbg.

With the JIT setting, WinDbg will be launched if an application throws an exception while not being debugged and does not handle the exception itself.

64-bit Debugging

All these debuggers support 64-bit debugging on AMD64 and IA64.

Managed Debugging

WinDbg 6.3+ supports managed debugging, with the Whidbey .NET CLR. There is a good discussion on managed debugging in the documentation. Remember that there are no PDBs with managed code since managed code is compiled to ILASM; the debugger talks to the CLR to query extra information.

Points to note:

You can set a breakpoint at a managed code function only after it has been invoked at least once; because that is when it is JIT-compiled to ASM code. Keep in mind:

  • Complications with function addresses and hence breakpoints:
    • The CLR can discard compiled code, so function addresses may change.
    • The same code may be multiply compiled if multiple app domains do not share the code. If you set a breakpoint, it gets set for the app domain of the current thread.
    • Specialization of generics can cause multiple addresses for the same function.
  • Complications with data layout and hence data inspection:
    • The CLR may change data layout arbitrarily at runtime, so field offsets in a structure may change over time.
    • Type information is loaded only on first use, so you may not be able to inspect a data field if it has not been used yet.
  • Complications with debugger commands:
    • When tracing through managed code, you would pass through chunks of runtime code like the JIT compiler code because you stepped into a function for the first time, or, when transitioning from managed to unmanaged code.

Debugging Services

You can debug a service just as any other application using WinDbg, both after starting the service by attaching to the service process, and, by using WinDbg as a JIT debugger and programmatically calling DbgBreakPoint or DebugBreak, or an ASM int 3 on x86.

Debugging Exceptions

A debugger gets notified of each exception twice – it is notified the first time before the application gets a chance to handle the exception (‘first chance exception’); if the application does not handle the exception, the debugger is given a chance to handle the exception ( ‘second-chance exception’). If the debugger does not handle a second-chance exception, the application quits.

.lastevent, or, !analyze –v will show you the exception record and stack trace of the function where the exception occurred.

You can also use the .exr, .cxr and .ecxr commands to display the exception and context records. Note also that you can change the first-chance handling option for an exception using the sxe, sxd, sxn and sxi commands.

WinDbg Features

Debugger Extension DLLs

Debugger extensions are DLLs that you can hook up with a debugger to execute custom commands from within the debugger. There are certain functions that a DLL needs to implement and some requirements that a DLL needs to meet in order to qualify as an extension DLL. In the next article, we shall learn how to write an extension DLL yourself. The bang (!) commands are commands executed from your extension DLLs. Note that extension DLLs are loaded in the process space of the debugger.

Dump Files

You can take snapshot information of a process using the dump facility. A mini-dump is usually small, unless you take a full-memory minidump (.dump /mf). It is useful to dump handle information also, as .dump/mfh. A mini-dump contains information about all threads including their stacks and list of loaded modules. A full dump contains more information, like that of the process heap.

Crash Dump Analysis

If your Windows OS crashes, it dumps the physical memory contents and all process information to a dump file, configured through System->Control Panel->Advanced->’Startup and Recovery’. It is also possible to take dumps of any live process by breaking into it. You can also take a dump of any process (.dump) that terminates abnormally by configuring WinDbg as a JIT debugger. Note that figuring out bugs in the code from a crash dump could be an involved process.

To analyze a dump, follow these steps:

Step 1: In WinDbg, File->’Open Crash Dump’, and point to the dump file

Step 2: WinDbg will show you the instruction your app was executing when it crashed.

Step 3: Set your symbol path and source path properly. If you cannot match symbols, you could have a hard time figuring out control flow. If you can match the symbols to source code of the appropriate version, it should be easy to figure out the bug at this point. Note that private symbol files have line number information and will blindly show the line in your source code without further checks; if your source is not version-matched properly, you’d not see the correct source code matching the assembly code. If you have public PDB files, you’ll see the last public function (on the call stack) that was invoked.

Note that debugging drivers or managed code is much different. Refer to [2] for debugging techniques for device drivers.

WinDbg Settings

Symbol Files and Directories

You need symbols in order to be able to do effective debugging. Symbol files could be in an older COFF format or the PDB format. PDBs are program database files and contain public symbols. These debuggers allow you to mention a list of URIs where they would look for symbols for loaded binaries.

OS symbols are usually installed in the %SYSTEMDIR%Symbols directory. Driver symbols (.DBG or .PDB files) are usually in the same folder as the driver (.sys file). Private symbol files contain information about functions, local and global variables, and line information to correlate assembly code to source code; symbol files that are usually made available to customers are public symbol files – these files contain information about public members only.

You can set symbol directories through File->Symbol File Path, or using .sympath from the WinDbg command window. To add reference to a symbol server on the web, add:

SRV*downstream_store*http://msdl.microsoft.com/download/symbols

to your .sympath, thus:

.sympath+ SRV*c:\tmp*http://msdl.microsoft.com/download/symbols

Where c:\tmp is the download_store where necessary symbols will be downloaded and stored. Note that this particular symbol server exposes public symbols only.

The debugger matches information like filename, timestamp and checksum when matching a PDB with a binary (DLL or exe). If you have symbol information, you’d be able to see function names and their arguments in your call stack. If the binaries and PDBs are from your application, you’d additionally have information about private functions, local variables and type information.

The sympath can consist of multiple URIs. Sympath is initialized from the _NT_SYMBOL_PATH system environment variable.

Source Code Directories

You can set source code directories through File->Source File Path, or using .srcpath from the WinDbg command window. If you set source code directories, the debugger will pull up matching source code based on line number information from the PDB files during debugging.

Breakpoints, Tracing

  • Set soft breakpoints using the bp commands or using the toolbar breakpoint icon.
  • Set hard breakpoints using code like DbgBreakPoint() or KdBreakPoint().
  • Use tracing routines DbgPrint, KdPrint, OutputDebugString to print out to the WinDbg output window, from debugger extension DLLs.

Commands

Basic Commands

The help file that comes with the WinDbg installation documents commands well, but the following basic commands should get you started:

FeatureCommandWhat Does it DoExample / CommentsSee Also Related Commands
     
Stack traceK, KB xDisplays stack trace of current thread (x frames). Kb causes the display to include the first three parameters passed to each function. KP, Kp, or KV
Frame.frame X   
Register watchRDisplays register set. reax – displays the eax register.  
SteptTrace = Step into (F11)  
 pStep over (F10)  
 Step outShift + F11  
DisassembleuUnassemble next few instructions  
 u <start_address>Unassemble instructions at start_address  
 u <start_address>

<end_address>

Unassemble instructions from start_address till end_address  
BreakpointsBlList breakpoints.  
 be, bd, bcEnable / disable / clear breakpoint.  
 bpSet a breakpoint.  
 buSet unresolved breakpoint. Breakpoint is resolved by symbolic name, not absolute address. Use this to set breakpoint at a function whose containing module has not yet been loaded.bu foo 
     
Comment*Ignores the command* Hello World 
ContinueG <address_X / symbol>Go. Resumes execution until address_X  
 GHGo, exception handled  
 GNGo, exception not handled  
QuitQ   
Dumping datadvDisplay local variables.You need private symbols. 
 Dd <address>Display dword values at specified address.To see value of an int, DD <addr> L1 
 Ds, da (ASCII), du (Unicode)Dump string  
 Dt [dt module!typedef adr]Dump type. Will dump the contents of the memory using typedef as a template.  
Change / Edit ValuesEb (byte), ed (dword), ea (ASCII), eu (Unicode)Edit value of a variable  
List moduleslmList loaded modules Lmi, lml, !dlls
Threads~Lists all threads  
Command on thread n~n<command>Switch to a specific thread by thread-id and execute a command on the thread.~2kb (second thread’s stack) 
     
Search for a symbol in a moduleX module!<pattern> X blah!*foo* 
Dump.dump   
Source line display.linesTurns on source code display  
 ln adrWill show the symbol nearest to that location.  
Note:
  1. There is no “step out” (Shift+F11). You have to find the return address on the stack manually and use “g adr”. You can find this address by using “k”. If you know the function uses ebp frames you can use “g poi(ebp+4)” to step out.
  2. To inspect local variables:
    1. Use the “dv” command.
    2. Then use the “dt <variablename>” command.
    3. Note: you may not see correct values if values are stored in registers or due to FPO.

More Commands

FeatureCommandWhat Does it DoExample / CommentsSee Also Related Commands
 VertargetShows information about the system on which you are debugging.  
Data breakpoint (hardware bp)Ba

[ba r/w/e size adr]

Sets a data breakpoint. You can break on read/ write/ execute attempt of a memory location.ba w4 adr 
Exceptions.lasteventDisplays last exception record  
ExceptionsSx, Sxe, sxd, sxn, sxi exception_XEnable/ disable/ notify-only/ ignore first chance exception /event exception_X. Example of event: module unload/ thread creation.  
Display typeDtShows struct and field values.Dt x; // x: int
Dt myStruct; // struct myStruct
Dt myStruct myVar1; // shows myStruct.myVar1
 
Reload symbols.reloadReloads symbols using the symbol path you would have set.  
Source linesl+l, l+o, l+s, l+tSource line options  
 .ecxrIf you had an exception, switches context to faulting context.  
 .quit_lock   
 ;Command separator  
 ?Evaluate expression  
 |Display process information  
 .chainLists all loaded debugger extensions.  
 .echo <string>Echo/ print any stringEcho xyz 
 .exr <address_x>Display exception record at x.  
 .cxr <address_x>Display context record at x.  
 .trapDump a trap frame.  

Handy Extension Commands

  • !help – help for WinDbg extension commands.
  • !load, !unload – to load and unload debugger extension DLLs.
  • !handle – displays information about handles owned by processes.
  • !peb - shows the PEB (process environment block) including DLL information.

Example

Attached is a sample application with these example functions:

  1. Example1: Program appears hung because a thread waits indefinitely on a critical section that another thread acquired and then exited without releasing.
  2. Example2: Exception: division by zero.
  3. Example3: Execute a command every time a breakpoint is hit.
  4. Example4: Exception: null pointer access
  5. Example5: Exception: double deletion
  6. Example6: Exception: stack overflow due to infinite recursion

Suggested Exercises

  1. Exception: Array out-of-bound access
  2. Exception: Deleted pointer access
  3. Exception: Stack underflow

Epilogue

Points to Note

Please note that:

  • when you run WinDbg, attach to a process and issue kb, you’d be seeing the stack trace of the thread injected by the debugger. All debugging commands are executed in the context of the injected thread.
  • Frame Pointer Omission (FPO):

    Means that when your code is compiled, frame pointers (EBP) will not be put on the stack. This makes function calls faster and makes the EBP register available as a scratch register. The optimization option /Oy in the MSC++ compiler => FPO; /O2 or /Ox (full optimization) => /Oy.

Q & A

  1. How can I list all symbols exported by a module?

    x <module>!*

  2. How can I find help for a specific command?

    .hh <command>, or <command> /?

  3. I want a certain application x.exe to run always under WinDbg. How can I configure this?

    Create a key named x.exe under “HKLM\Software\Microsoft\Windows NT\currentversion\image file execution options” and add a new string value “Debugger” to it; set its value to the path of windbg.exe.

  4. I want to do something every time a breakpoint is hit. How can I do that?

    The bp command accepts a list of commands as argument that you can execute every time a breakpoint is hit. Example:

    bp WindbgEx1!Example3+0x3d "dd [ebp-0x14] L1; .echo hello world;g"

    (ref. attached code)

    prints the value of a local variable in each iteration of function Example3.

  5. Can I put a breakpoint that is triggered only once?

    Yes:bp /1

  6. Can I set a breakpoint such that it will start hitting only after k-1 passes?

    Yes, bp <address> k

References

  1. WinDbg documentation [from Microsoft]
  2. “The Windows 2000 Device Driver Book” – Art Baker, Jerry Lozano

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here


Written By
Web Developer
United States United States
I am a software developer based in Seattle, Washington. I used to work for Lucent in New York.

Comments and Discussions

 
GeneralRe: windbg vs devstudio Pin
Thomas Lunsford27-Jan-05 5:46
Thomas Lunsford27-Jan-05 5:46 
GeneralGreat article Pin
Pavel Lebedinsky15-Feb-04 22:51
sussPavel Lebedinsky15-Feb-04 22:51 
GeneralRe: Great article Pin
Pavel Lebedinsky15-Feb-04 23:14
sussPavel Lebedinsky15-Feb-04 23:14 
GeneralRe: Great article Pin
Nemanja Trifunovic16-Feb-04 7:26
Nemanja Trifunovic16-Feb-04 7:26 
GeneralRe: Great article Pin
Saikat Sen16-Feb-04 8:36
Saikat Sen16-Feb-04 8:36 
GeneralRe: Great article Pin
Nathan Nesbit28-Feb-04 17:09
sussNathan Nesbit28-Feb-04 17:09 
GeneralThanks. Pin
John M. Drescher15-Feb-04 0:38
John M. Drescher15-Feb-04 0:38 
GeneralRe: Thanks. Pin
Saikat Sen16-Feb-04 8:48
Saikat Sen16-Feb-04 8:48 
Thanks for your feedback, John. I have found Windbg very handy for remote debugging scenarios.
I look forward to your comments on why you went off from using Windbg - I am presuming you started using Visual Studio.

- Saikat
GeneralRe: Thanks. Pin
John M. Drescher16-Feb-04 9:04
John M. Drescher16-Feb-04 9:04 
GeneralRe: remote debugging Pin
Saikat Sen17-Feb-04 15:43
Saikat Sen17-Feb-04 15:43 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.