Beginner guide to WinDbg – Part 1

Download pdf version from here

Introduction

WinDBG is a debugging tool from Microsoft for user and kernel mode debugging. WinDBG is a GUI interface built on CDB, NTSD and KD along with debugging extensions. We will mainly be using WinDBG along with SOS extension for managed code debugging.
WinDBG is a very powerful tool for debugging and it allows you to set a breakpoint, view source code using symbol files, view stack trace, parameters to a method, memory and registers. Please refer to the below link to download WinDBG

http://www.microsoft.com/whdc/DevTools/Debugging/default.mspx

Once you have installed Debugging Tools for Windows, you can instantiate WinDBG from Start->Programs->Debugging Tools for Windows(x86)->WinDbg

We recommend you to read and read and read WinDBG Help that will be your only source on documentation.

Below are the options you have to access WinDbg Help

    1. Start->Programs->Debugging Tools for Windows(x86)->Debugging Help (on x86)

    2. Launch WinDbg and Click on Help Menu as shown in the snapshot below

help snapshot

  1. Go to WinDBG Installed Folder(Default location on x86 is “c:\program files\Debugging
    Tools for Windows (x86))”
    WinDBG Help Snapshot

Please note that when you see a command starting with kd> on help, these commands are for kernel debugging. ThoseKD commands will not run in user mode debugging. They can’t be used to debug a win32 user mode process.

Memory Dumps
Memory dump is a snapshot of the memory and register at the time of crash. You can also collect a memory of a process to get the snapshot of a process’s memory at a particular instance.

User Mode Dump

User Mode Dump includes the virtual memory information, process environment block, process and thread structures to assist in debugging.

  1. Full Dump – includes all the information about a process(exe) including committed virtual memory page, thread and process data structures, handle data, loaded and unloaded modules and their addresses.

  2. Mini Dump – includes only specific memory snapshot of a process. Although, the name is minidump but it can be larger than full dump depending on the dump option you choose.

As described in WinDBG help

The name “minidump” is misleading, because the largest minidump files actually contain more information than the “full” user-mode dump. For example, .dump /mfor .dump /mawill create a larger and more complete file than .dump /f. For this reason, .dump /m[MiniOptions] recommended over .dump /ffor all user-mode dump file creation.

If you are creating a minidump file with the debugger, you can choose exactly what information to include. A simple .dump /m command will include basic information about the loaded modules that make up the target process, thread information, and stack information.

What dump to collect for a Win32 User Mode Process?

As described in ADPlus.vbs

ADPlus has 3 modes of operation: ‘Hang‘, ‘Quick‘ and ‘Crash‘ mode.

Hang Mode

In ‘Hang’ mode, ADPlus assumes that a process is hung and it will attach a debugger to the process(s) specified on the command line. After the debugger is attached to the process(s) ADPlus will dump the memory of each process to a .dmp file for later analysis with a debugger (such as WinDBG). In this mode, processes are paused briefly while their memory is being dumped to a file and then resumed.

Quick Mode

In ‘-quick’ mode ADPlus assumes that a process is hung and it will attach a debugger to the process(s) specified on the command line with either the ‘-p’ or ‘-pn’ or ‘-iis’ switches. After the debugger is attached to the process(s) ADPlus will create mini dumps for each process, containing commonly requested debug information, rather than dumping the entire memory for each process.’Quick’ mode is generally faster than ‘Hang’ mode, but requires symbols to be installed on the server where ADPlus is running.

Crash Mode

In ‘Crash’ mode, ADPlus assumes that a process will crash and it will attach a debugger to the process(s) specified on the command line with either the ‘-p’ or ‘-pn’ or ‘-iis’ switches. After the debugger is attached to the process(s)ADPlus will configure the debugger to log ‘first chance’ access violations (AV’s) to a text file. When a ‘second chance’ access violation occurs, the processes memory is dumped to a .dmp file for analysis with a debugger such as WinDBG. In this mode, a debugger remains attached to the process(s) until the process exits or the debugger is exited by pressing CTRL-C in the minimized debugger window. When the process crashes, or CTRL-C is pressed, it will need to be re-started.

Hang Dump Check List

  1. Memory Leak?

  2. High CPU Usage, Performance?

  3. Process Hang/Deadlock?

  4. Analyze the state of an application at a particular instance?


Crash Dump Check List

 

  1. Application crashing due to unhandled exception?

  2. Unexpected behavior due to a handled exception or a first chance exception?

How to Collect Memory Dump using ADPlus(visual basic script)

ADPlus.vbs file is installed in a default location with Debugging tools for Windows

The best source for ADPlus documentation is winDBG help as shown in below snapshot. You can also open the ADPlus.vbs file to explore all the options because it seems to be well documented.

WinDbg ADPlus Help

Steps to collect hang memory dump using ADPlus

  1. If WinDBG is not installed on a system, follow http://www.microsoft.com/whdc/DevTools/Debugging/default.mspx to download WinDbg for 32bit OS or 64 bit OS depending on the version of windows OS .

  2. Please note that WinDBG supports XCOPY so you can either install it directly on a system or you can choose to install it on a test system and copy the installed folder on a production machine. Sometime XCOPY is desirable for security reasons and if you don’t want to get a permission to install a software. By Default, Debugging Tools for Windows get installed under “\Program Files\Debugging Tools for Winodws\”

  3. Open command prompt window and go to the installed folder. Run the command as shown below(Figure 1)

cscript.exe – to specify cscript.exe script interpreter to run vbscript.exe otherwise it will try to set cscript.exe as default script interpreter

adplus.vbs – vbscript file to generate memory dump

-hang – As described in adplus.vbs file(copy and paste), ADPlus has 3 modes of operation: ‘Hang’, ‘Quick’ and ‘Crash’ mode. In ‘Hang’ mode, ADPlus assumes that a process is hung and it will attach a debugger to the process(s) specified on the command line with either the ‘-p’ or ‘-pn’ or ‘-iis’ switches. After the debugger is attached to the process(s) ADPlus will dump the memory of each process to a .dmp file for later analysis with a debugger (such as WinDBG). In this mode, processes are paused briefly while their memory is being dumped to a file and then resumed.

-pn Adplus supports -pn and -p switch to specify the name or process id of an application

notepad.exeprocess to be debugged to generate memory dump

-quietADPlus support quiet mode to suppress the dialog boxes as shown below in Figure 2 and Figure 3
cscript adplus script snapshot

Figure 1

ADPlus warning messagebox snapshot

Figure 2

ADPlus windows script host warning message

Figure 3

  1. The name of executable specified in -pn switch must not contain drive or folder path. Process name should be specified as shown in the Task Manager.

  2. By default, the Adplus script will create subfolder similar to the following Hang_Mode__Date_mm-ddyyyy__Time_hh-mm-ssAM/PM. This subfolder will be created under C:\WinDBG\, folder will contain debugger logs and a memory dump.

  3. Default destination for memory dumps can be changed with –o switch as show belowADPlus script command windows snapshot
  4. You can also use -p switch and get the process ID from task manager, -p switch comes handy when a process name is not complete in task manager or if you have the multiple instances of a process running for exampleasp.net worker process(w3wp.exe)

Important Note

    • You should collect more than one memory dump at different intervals to analyze the application state and to find out what objects have survived garbage collection or to analyze deadlock/hang
    • You may want to collect memory dump right after garbage collection to analyze managed memory issue. You could probably make it configurable which will ensure that GC.Collect() is called along with GC.WaitForPendingFinalizers()
    • -r Repeats IntervalInSeconds , ADPlus supports -r switch to enable repeated hang attachments. However, this switch is supported only in hang mode and this is ignored in crash mode. IntervalInSeconds specifies the interval, in seconds, between each run

 

Steps to collect crash memory dump using ADPlus

same as above just replace the -hang switch to -crash.

Followings are the additional switches you should know to collect crash dump

-FullOnFirst
This will create a full dump on first chance exception. Remember, you can’t do managed heap analysis unless you have a full dump. Sometime, you do want to get a full dump in case you are noticing unexpected behavior after a first chance exception has occurred. You may want to analyze application state, handles, objects on heap or data structures. Since there could be several first chance exceptions this may really slow down your application since it has to dump the memory on every single first chance exception. The default behavior is to have minidumps created on first chance.You are better off using a configuration file if you already know the exception type.
(below descriptions as documented in WinDbg)
-MiniOnSecond
Creates minidumps on second chance for all defined exceptions. The default behavior is to have full dumps created on second chance.
-NoDumpOnFirst
Creates no dumps on first chance for all defined exceptions. The default behavior is to have minidumps created on first chance.
-NoDumpOnSecond
Creates no dumps on second chance for all defined exceptions. The default behavior is to have full dumps created on second chance.

Continue – WinDBG commands and Dump Analysis in Beginner’s Guide to WinDBG – Part 2

Category: WinDbg
  • GDJared says:

    Спасибо!

    [Reply]

    November 6, 2008 at 12:30 am
  • olher says:

    Как тебе новость на премьершипе:

    “Тоттенхэм хочет приобрести Шея Гивена.
    Главный тренер лондонского “Тоттенхэма” Харри Рэднапп признался, что он является личным поклонником таланта голкипера “Ньюкасла” Шея Гивена и хотел бы заполучить этого игрока в свой клуб.
    “Шей Гивен – великолепный голкипер, я им восхищаюсь. Любой тренер хотел бы его приобрести, если бы это был возможно”, – цитирует Рэднаппа газета Daily Mail.”

    [Reply]

    November 7, 2008 at 7:42 am
  • линкомаулия says:

    Неплохой пост, но много лишнего.

    [Reply]

    February 17, 2009 at 10:30 pm
  • Brian says:

    great tutorial easy to understand, keep up the good work.

    [Reply]

    May 16, 2009 at 7:54 pm
  • Worssnusisp says:

    Интересненько, а кто может объяснить девушке как добавить этот блог в избранное?

    [Reply]

    July 17, 2009 at 4:49 am
  • Mike says:

    Hi,

    I have installed and implemented adplus on a Windows 2008 Server but with no success although the same configuration and implementation works on a Windows 2003 server. I get the following error on 2008 :

    C:\Program Files\Debugging Tools for Windows 64-bit>cscript adplus.vbs -crash -p
    n Icrash2 -o c:\adplus
    Microsoft (R) Windows Script Host Version 5.7
    Copyright (C) Microsoft Corporation. All rights reserved.

    The following requested processes are not executing:
    ICRASH2;

    The ICRASH2 program is just a little C++ script that mimics a crash.

    Any ideas?

    [Reply]

    prashant Reply:

    @Mike, That just means that ICRASH2 process is not running. Before you run execute adplus.vbs, you can execute tlist.exe to see the list of running processes as seen by adplus script.
    I would think that this is most likely the issue with ICRASH2 on windows server 2008. It may be crashing before you even attach the debugger. If that’s the case then you can even set WinDBG as the default post mortem debugger to verify the cause of crash since you are not getting the chance to attach the debugger.
    Please refer to http://support.citrix.com/article/ctx107528 to enable WinDBG as the default post mortem debugger

    [Reply]

    January 19, 2010 at 11:38 am
  • Mike says:

    Hi,

    Thanks for the reply. The ICRASH program was a simple C++ program written by one of my development colleague’s to mimic a crash. So when I run the ICRASH.exe all it does is run, open a dos prompt and says “Press Enter to Crash” once return is pressed the process crashes. This is just to test the WinDBG in a production enviroment. So I’m confident that the process is running and this is confirmed by running tlist.exe and in fact I get the same error when I try it with a production process. The frustrating thing is that it works fine with a windows 2003 server. I know this isn’t a help forum, so I appreciate your response.

    Mike

    [Reply]

    prashant Reply:

    @Mike, That’s interesting. Is your server 32 bit or 64 bit? Unless you have already verified, you should check the WinDBG 32 or 64 bit based on the processor. If you are still having the issue, then just zip the exe and email it to me prashant@debuggingblog.com. Please also let me know if its 32 or 64 bit server. No problem at all, I am also curious about this issue.

    [Reply]

    January 20, 2010 at 7:41 am
  • merwindz says:

    I have file server hang ( freezing) issue and If I want to trobleshoot which process causing this how do I do and which process should be debuging?

    [Reply]

    April 22, 2010 at 12:11 pm
  • Babu says:

    Good

    [Reply]

    April 16, 2013 at 1:17 pm

Your email address will not be published. Required fields are marked *

*