WinDBG: The very basics

nommy the first · 04 Nov 2013

As some of you might know, I only recently started analyzing dump files and contributing to the BSoD Help and Support subforum. In the past two or three months that I've been busy with this I have received more support from BSoD Team members than I could ever have hoped for.
So I want to give something back; to SevenForums, the BSoD Team and most important, to people who want to begin with analyzing dump files, because I know all to well how hard it can be:)

1.

Installing WinDBG

As the title says, you'll first need to download and install WinDBG on your machine, so that you have a program to open and interpret the dump files. So let's install it:

You can download the latest version of WinDBG here (currently 8.1).
Note that there are three downloads on that site, WDK, SDK and a stand alone set.
WDK means Windows Driver Kit.
SDK means Software Development Kit.
All of these downloads contain WinDBG, but we will download the SDK by clicking on get the Windows SDK here.

After going to the download page, click on the download link as displayed on the image below;

WinDBG: The very basics-download-sdk.jpg

After downloading the file and running it, you will see a screen where you can select the features that you want to download, uncheck everything other than WinDBG.

WinDBG: The very basics-only-select-debugging-tools.png

Now that you've downloaded WinDBG you'll need to install .NET Framework 4.5.2 before installing WinDBG.
You can download .NET Framework 4.5.2 here.

After downloading and installing .NET Framework 4.5.2 please restart your machine and then run the installer for WinDBG. Follow the onscreen instructions to install it.

After installing WinDBG and running it, you'll need to "install" a file path so that WinDBG can read the symbols in the dump files.
To do this, please open WinDBG, click on File and then click on Symbol File Path ....
Now please paste the following in the text box;
SRV*c:\symbols*http://msdl.microsoft.com/download/symbols

Now click on OK and close WinDBG. It will ask you if you want to save your workspace, accept it so what WinDBG will remember the symbol file path and click on Don't ask again so that you'll never need to do it again.

WinDBG: The very basics-windbg-symbol-path-fix.png

Congrats, you now have a fully functional version of WinDBG installed on your system!

2.

Opening Dump Files

Option one.
Now that you have WinDBG installed on your system, you'll want to know how to open and read dump files, so allow me to explain it.

First open WinDBG and then click on File. Now click on Open Crash Dump.

WinDBG: The very basics-open-crash-dump.png

Now a new window will open, in which you need to navigate to the desired dump file that you want to open.

Option two.
Alternatively, you can associate dump files with WinDBG so that whenever you double click a dump file, it will automatically be opened with WinDBG.

To do this, open an Elevated Command Prompt and paste the following;
"C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x64\windbg.exe" -IA

To paste something in CMD, click on the CMD icon in the upper left corner, then click on Edit and then on Paste. Now hit enter.

Note

The location in the highlighted line depends on where you have installed WinDBG.
To find it's location type "winDBG" in the search bar, right click it and select Properties. Now copy the line next to Target and replace the highlighted location with that.

3.

Interpreting dump files

As said in the title, I will only go over the most basic functions here, as there are plenty of tutorials/blogs out there which explain the more advanced functions.

Once you've opened a dump file, it will look like this;

This is a dump file generated by my own machine.

Code:

Microsoft (R) Windows Debugger Version 6.2.9200.20512 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\Users\Stefan\Desktop\ \SF_27-08-2013\082713-55505-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: SRV*c:\symbols*http://msdl.microsoft.com/download/symbols
Executable search path is: 
Windows 7 Kernel Version 7601 (Service Pack 1) MP (4 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS Personal
Built by: 7601.18205.amd64fre.win7sp1_gdr.130708-1532
Machine Name:
Kernel base = 0xfffff800`02e4d000 PsLoadedModuleList = 0xfffff800`030906d0
Debug session time: Mon Aug 26 23:24:31.039 2013 (UTC + 1:00)
System Uptime: 11 days 5:14:58.139
Loading Kernel Symbols
...............................................................
................................................................
...............................
Loading User Symbols
Loading unloaded module list
..................................................
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck FC, {fffff8a009000100, 8400000165cf5121, fffff8800655f600, 2}

*** WARNING: Unable to verify timestamp for asmtxhci.sys
*** ERROR: Module load completed but symbols could not be loaded for asmtxhci.sys
Probably caused by : asmtxhci.sys ( asmtxhci+1edcf )

Followup: MachineOwner
---------

A lot of text isn't it?
My first and most important advice here is don't panic! It might seen like a lot of gibberish at first sight, but once I've explained it a bit you'll see that it isn't all that bad:)

The first part, everything above "BugCheck Analysis", you can ignore for now.

Basically you'll see three things in this analysis;
1. "Use !analyze -v to get detailed debugging information."
!analyze -v is a command which you can use to, for instance, obtain the stack trace of the dump file, I will explain this command and the stack trace later on.

2. "BugCheck FC, {fffff8a009000100, 8400000165cf5121, fffff8800655f600, 2}"
This is the error, or as it is officially called, the stop code.
Most stop codes can be found at the MSDN site, which is here. What I do and what I recommend you to do too is to simply put the bugcheck code in Google. 9 out of 10 times the first link will be the specific MSDN page.
If we look at this stop code, we see that it refers to this MSDN page.

MSDN said:

Bug Check 0xFC:
ATTEMPTED_EXECUTE_OF_NOEXECUTE_MEMORY
The ATTEMPTED_EXECUTE_OF_NOEXECUTE_MEMORY bug check has a value of 0x000000FC.
This indicates that an attempt was made to execute non-executable memory.

Source: Bug Check 0xFC: ATTEMPTED_EXECUTE_OF_NOEXECUTE_MEMORY (Windows Debuggers)

I will not further analyze this dump file or stop code, as that is not the goal of this thread.

3. "*** WARNING: Unable to verify timestamp for asmtxhci.sys
*** ERROR: Module load completed but symbols could not be loaded for asmtxhci.sys
Probably caused by : asmtxhci.sys ( asmtxhci+1edcf )"

A lot of words, but basically all that's said is "hey, asmtxhci.sys is the failing driver, take a look there!".
Now your next step is to figure out what on earth that driver does. To do this we have the something called the Driver Reference Table.
You can find it here.

Information

Long list eh?
I bet that you don't want to look through it entirely just to find one pesky driver.
Well neither do I, do why don't we ease the search a bit:)

Simply hit Ctrl+F to open up the "Find in page" menu, and type/paste the driver name there.

If we search for the failing driver from my dump file there, we'll be directed to this page.

Carrona said:

Driver Description: Asmedia USB 3.0 driver

Driver Update Site: ASMedia Technology Inc. ????

Source: Driver Reference Table - asmtxhci.sys

And there is your problem; the USB port driver was failing, and the link to update said driver is displayed under there.

4.

!analyze -v

Now let's use the !analyze -v command to see what we get;

Code:

2: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

ATTEMPTED_EXECUTE_OF_NOEXECUTE_MEMORY (fc)
An attempt was made to execute non-executable memory.  The guilty driver
is on the stack trace (and is typically the current instruction pointer).
When possible, the guilty driver's name (Unicode string) is printed on
the bugcheck screen and saved in KiBugCheckDriver.
Arguments:
Arg1: fffff8a009000100, Virtual address for the attempted execute.
Arg2: 8400000165cf5121, PTE contents.
Arg3: fffff8800655f600, (reserved)
Arg4: 0000000000000002, (reserved)

Debugging Details:
------------------


CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  WIN7_DRIVER_FAULT

BUGCHECK_STR:  0xFC

PROCESS_NAME:  System

CURRENT_IRQL:  0

TRAP_FRAME:  fffff8800655f600 -- (.trap 0xfffff8800655f600)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=fffff8a009000100 rbx=0000000000000000 rcx=fffffa80080ca570
rdx=000000008018e235 rsi=0000000000000000 rdi=0000000000000000
rip=fffff8a009000100 rsp=fffff8800655f798 rbp=fffff8800655f7f0
 r8=fffff8800655f7f0  r9=fffff8800655f7f0 r10=00000000fffffff7
r11=fffff8800655f980 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei ng nz na po nc
fffff8a0`09000100 0035002c0020    add     byte ptr [fffff8a0`29002d06],dh ds:fffff8a0`29002d06=??
Resetting default scope

LAST_CONTROL_TRANSFER:  from fffff80002f408a8 to fffff80002ec2b80

STACK_TEXT:  
fffff880`0655f498 fffff800`02f408a8 : 00000000`000000fc fffff8a0`09000100 84000001`65cf5121 fffff880`0655f600 : nt!KeBugCheckEx
fffff880`0655f4a0 fffff800`02ec0cae : 00000000`00000008 fffff8a0`09000100 00000000`00000000 fffffa80`080ca570 : nt! ?? ::FNODOBFM::`string'+0x44dfc
fffff880`0655f600 fffff8a0`09000100 : fffff880`088b2dcf 00000000`00000020 fffff800`02e9ce7a 00000000`00000002 : nt!KiPageFault+0x16e
fffff880`0655f798 fffff880`088b2dcf : 00000000`00000020 fffff800`02e9ce7a 00000000`00000002 00000000`00000000 : 0xfffff8a0`09000100
fffff880`0655f7a0 00000000`00000020 : fffff800`02e9ce7a 00000000`00000002 00000000`00000000 fffff800`03052728 : asmtxhci+0x1edcf
fffff880`0655f7a8 fffff800`02e9ce7a : 00000000`00000002 00000000`00000000 fffff800`03052728 fffff880`088aad6c : 0x20
fffff880`0655f7b0 00000000`00000001 : 00000000`00000005 00000000`00000000 fffffa80`080ca570 00000000`00000000 : nt!KeCancelTimer+0x1a
fffff880`0655f7e0 00000000`00000005 : 00000000`00000000 fffffa80`080ca570 00000000`00000000 00000000`00000000 : 0x1
fffff880`0655f7e8 00000000`00000000 : fffffa80`080ca570 00000000`00000000 00000000`00000000 fffff880`088b2f77 : 0x5


STACK_COMMAND:  kb

FOLLOWUP_IP: 
asmtxhci+1edcf
fffff880`088b2dcf ??              ???

SYMBOL_STACK_INDEX:  4

SYMBOL_NAME:  asmtxhci+1edcf

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: asmtxhci

IMAGE_NAME:  asmtxhci.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  4de6f522

FAILURE_BUCKET_ID:  X64_0xFC_asmtxhci+1edcf

BUCKET_ID:  X64_0xFC_asmtxhci+1edcf

Followup: MachineOwner
---------

Hrm, even more text. Again, don't panic! Relax, take a breath and sit back.

Everything above the "Debugging details" isn't of use to us; it's the exact same info that is displayed on the MSDN website we just checked.

Basically all you need to check here for now is the stack trace, or as it is called in WinDBG, the STACK_TEXT;

Code:

fffff880`0655f498 fffff800`02f408a8 : 00000000`000000fc fffff8a0`09000100 84000001`65cf5121 fffff880`0655f600 : nt!KeBugCheckEx
fffff880`0655f4a0 fffff800`02ec0cae : 00000000`00000008 fffff8a0`09000100 00000000`00000000 fffffa80`080ca570 : nt! ?? ::FNODOBFM::`string'+0x44dfc
fffff880`0655f600 fffff8a0`09000100 : fffff880`088b2dcf 00000000`00000020 fffff800`02e9ce7a 00000000`00000002 : nt!KiPageFault+0x16e
fffff880`0655f798 fffff880`088b2dcf : 00000000`00000020 fffff800`02e9ce7a 00000000`00000002 00000000`00000000 : 0xfffff8a0`09000100
fffff880`0655f7a0 00000000`00000020 : fffff800`02e9ce7a 00000000`00000002 00000000`00000000 fffff800`03052728 : asmtxhci+0x1edcf
fffff880`0655f7a8 fffff800`02e9ce7a : 00000000`00000002 00000000`00000000 fffff800`03052728 fffff880`088aad6c : 0x20
fffff880`0655f7b0 00000000`00000001 : 00000000`00000005 00000000`00000000 fffffa80`080ca570 00000000`00000000 : nt!KeCancelTimer+0x1a
fffff880`0655f7e0 00000000`00000005 : 00000000`00000000 fffffa80`080ca570 00000000`00000000 00000000`00000000 : 0x1
fffff880`0655f7e8 00000000`00000000 : fffffa80`080ca570 00000000`00000000 00000000`00000000 fffff880`088b2f77 : 0x5

Firstly, the stack trace is to be read from bottom to top. Right now this will be of very little use to you, as you most likely don't have a clue what stack traces are and what they're good for, but now you know it anyway:)
That said, I will not explain what stack traces are or anything related, as there are plenty of tutorials out there that do this.

Basically all that you, as beginning crash dump analyst, need to do here, is look for something that resembles a driver name.
As we have seen in the previous step, asmtxhci.sys is the failing driver, and when we look at the fifth line, we see "asmtxhci+0x1edcf".
There you have it, the failing driver.

5.

lmvm command

This command will display more detailed information about one specific driver. Let's use it on asmtxhci.sys to see what we get;

Code:

2: kd> lmvm asmtxhci
start             end                 module name
fffff880`08894000 fffff880`088f9000   asmtxhci T (no symbols)           
    Loaded symbol image file: asmtxhci.sys
    Image path: \SystemRoot\system32\DRIVERS\asmtxhci.sys
    Image name: asmtxhci.sys
    Timestamp:        Thu Jun 02 04:27:46 2011 (4DE6F522)
    CheckSum:         0006BE1F
    ImageSize:        00065000
    Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4

Let's start at the beginning.
To use this command you'll need to type lmvm <failing driver name>.

As we see in my example looking at the "timestamp", we see that the driver installed dates back to 2011, this is very old. My advice is that every driver that dates before December 2012 or January 2013 should be updated.

To check for updates, you can search for the driver name in the Driver Reference Table and then click on the link in the third column. 9 out of the 10 times this will take you to the download page of the driver.
If not, simply search for the driver name in Google.

Note

Windows drivers or drivers that are in red in the Driver Reference Table don't need to be uploaded, as there most likely aren't any updates available.

Now there are plenty of other tutorials, blogs, websites and even entire online communities dedicated to debugging dump files, but this are the basics. Here are some useful links you can read as a beginning crash dump analyst;

Special thanks to the following members which all greatly supported me:
Arc, thanks for assisting me in numerous threads, offering support when I needed it and helping me start up with debugging.
Northernsoul55, thanks for helping me with some OP's which I couldn't figure out on my own.
Koolkat77, thanks for your tutorials which got me into debugging in the first place, they have been and still are very useful.
YoYo155, thanks for answering the questions I had and allowing me to follow your threads.
x BlueRobot, thanks for your blog and all of the useful links you have provided.

Hope that this will be helpful for someone:)
Nommy

Arc · 04 Nov 2013

Nice one mate.

Add the windbg -IA command in step 2, which will help the user to open the dumps in windbg by double clicking the dump file?

nommy the first · 04 Nov 2013

Arc said:

Nice one mate.

Add the windbg -IA command in step 2, which will help the user to open the dumps in windbg by double clicking the dump file?

Thanks:) I added the command as an option in step two.

Nommy

x BlueRobot · 04 Nov 2013

Great tutorial :)

nommy the first · 04 Nov 2013

Thanks Harry

Nommy

x BlueRobot · 04 Nov 2013

Stefan, maybe you should also add a link to this thread, which has a full list of debugging tutorials/blogs/forums etc. - BSOD Tutorials and Information Links

I've recently added another link too.

nommy the first · 05 Nov 2013

Thanks Harry, added the link:)

Change log:
Added:
1. Command Prompt command to associate file types.
2. Corrected several spelling errors.
3. Added link to BSoD Tutorial and Information thread.

Planning to add:
1. Information about lmvm command.
2. Elaborate Carrona a bit and explain other uses besides DRT.
3. Add importance of canned speeches and possible examples for new contributors.
4. Possibly add short list of possible "probably caused by" and shortly explain the followup.

Nommy

nommy the first · 05 Nov 2013

Change log:
Added:
1. Lmvm command explanation.
2. Corrected spelling mistakes.

Planning to add:
1. Elaborate Carrona a bit and explain other uses besides DRT.
2. Add importance of canned speeches and possible examples for new contributors.
3. Possibly add short list of possible "probably caused by" and shortly explain the followup.

Nommy

x BlueRobot · 05 Nov 2013

Good new additions to the new tutorial :)

Another tip, you might be able to squeeze in, is if you see Windows networking drivers or file system drivers, then I would suggest checking for Internet Security suites and any virtual drive emulator programs/anti-virus programs, which could potentially be causing problems indirectly.

koolkat77 · 05 Nov 2013

Great looking tutorial! Good job Stefan :)