New
#1
WinDBG: The very basics
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;
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.
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.
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.
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.
NoteThe 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.
A lot of text isn't it?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 ---------
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.
I will not further analyze this dump file or stop code, as that is not the goal of this thread.MSDN said:
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.If we search for the failing driver from my dump file there, we'll be directed to this page.InformationLong 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.
And there is your problem; the USB port driver was failing, and the link to update said driver is displayed under there.Carrona said:
4.!analyze -v
Now let's use the !analyze -v command to see what we get;
Hrm, even more text. Again, don't panic! Relax, take a breath and sit back.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 ---------
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;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:)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
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;Let's start at the beginning.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
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.NoteWindows 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;
- Debugging A BSOD - My way
- Windows Debuggers: Part 1: A WinDbg Tutorial - CodeProject
- www.carrona.org
- http://www.windbg.info/doc/1-common-cmds.html
- Analyze -v
- MSDN Blogs
- BSODTutorials
- Crash and lockup debug 'How To' - Windows 7 Help Forums
- BSOD Tutorials and Information Links
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
Last edited by nommy the first; 17 Jul 2014 at 06:22. Reason: Corrected grammatical errors.