Windbg Minidump Tutorial:Setting up & Reading Minidump Files

This is a tutorial on how to set up and read your minidump files when you receive a BSOD (blue screen of death) in the attempts to gain further insight as to the cause of the problem. First thing is first. Download the latest debugging tools from the Microsoft site. Search for "debugging tools microsoft" in Google.

Then go to Start/Start Search. Type i
the command <i>cmd</i>.

Then change directories to:

C:Program FilesDebugging Tools for Windows (x86)

by using the command:

cd c:program filesdebugging tools for windows (x86)

It's case insensitive when using the <i>cd</i> command.

Then type in:
windbg.exe -z c:windowsminidumpmini061909-01.dmp -c "!analyze -v"

Your minidump file is located at C:WindowsMinidumpMini062009-01.dmp. It'll be in the form "MiniMMDDYY-01.dmp".

KERNEL SYMBOLS ARE WRONG. PLEASE FIX SYMBOLS TO DO ANALYSIS

If somewhere in the output of the Bugcheck Analysis you see an error like:

***** Kernel symbols are WRONG. Please fix symbols to do analysis.

Then it's most likely that you are using previous and incompatible symbols or corrupt files or you don't have the proper symbols at the specified location when the Windbg program was trying to analyze the minidump file. So what I did was open up the Windbg program located at C:Program FilesDebugging Tools for Windows (x86) (in Vista and I believe it's the same location for XP).

SETTING THE SYMBOL FILE PATH VIA WINDBG COMMAND LINE:

This is an important step so ensure that your symbol path file is set correctly lest you get the kernel symbols are WRONG error or other types of errors. Now set the Symbol File Path (File/Symbol File Path) to:

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

However, for some reason I found that in order to set the Symbol File Path in the "File/Symbol File Path" field you cannot change it directly with the field of "File/Symbol File Path". So what I found that you need to change it through the Windbg command window by going to:

"View/Command"

In the bottom of the command window beside the "kd>" prompt type this in:

.sympath SRV*e:symbols*http://msdl.microsoft.com/download/symbols

The part between the two asterisks (*) is where the symbols from Microsoft's servers will be downloaded to. It's fairly large (approximately 22MB) so make sure that you have sufficient disk space.

SETTING SYMBOL FILE PATH IN THE ENVIRONMENT VARIABLE:

Alternatively, you can set it in your environment variable either in your system or user environment variable. To do this, click the WINDOWS KEY+e. The WINDOWS KEY is the key to the right of the LEFT CTRL key of the keyboard. This will open up Windows Explorer.

Then click on the "Advanced system settings" at the top left of the window. This step applies to Vista only. For XP users, simply click on the Advanced tab.

Then click on the button "Environment variable" at the bottom of the window.

Then click on the "New" button under System Variables. Again you can create the environment as a user environment variable instead.

In the "Variable Name" type:
_NT_SYMBOL_PATH

In the "Variable Value" type:
symsrv*symsrv.dll*e:symbols*http://msdl.microsoft.com/download/symbols

If you set the symbol file path as a system environment variable I believe you may have to reboot your computer in order for it to take effect.

OUTPUT OF WINDBG COMMAND

So the following is the output for my crash:

Microsoft (R) Windows Debugger Version 6.11.0001.404 X86
Copyright (c) Microsoft Corporation. All rights reserved.

Loading Dump File [c:windowsminidumpmini062609-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: SRV*e:symbols*http://msdl.microsoft.com/download/symbols;I:symbols
Executable search path is:
Windows Server 2008/Windows Vista Kernel Version 6001 (Service Pack 1) MP (2 procs) Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS Personal
Built by: 6001.18226.x86fre.vistasp1_gdr.090302-1506
Machine Name:
Kernel base = 0x8201d000 PsLoadedModuleList = 0x82134c70
Debug session time: Fri Jun 26 16:25:11.288 2009 (GMT-7)
System Uptime: 0 days 21:39:36.148
Loading Kernel Symbols
...............................................................
................................................................
...........................................................
Loading User Symbols
Loading unloaded module list
............................
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck A, {8cb5bcc0, 1b, 1, 820d0c1f}

Unable to load image SystemRootsystem32DRIVERSSymIMv.sys, Win32 error 0n2
*** WARNING: Unable to verify timestamp for SymIMv.sys
*** ERROR: Module load completed but symbols could not be loaded for SymIMv.sys
Unable to load image SystemRootsystem32DRIVERSNETw3v32.sys, Win32 error 0n2
*** WARNING: Unable to verify timestamp for NETw3v32.sys
*** ERROR: Module load completed but symbols could not be loaded for NETw3v32.sys
Processing initial command '!analyze -v'
Probably caused by : tdx.sys ( tdx!TdxMessageTlRequestComplete+94 )

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

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

IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high.  This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 8cb5bcc0, memory referenced
Arg2: 0000001b, IRQL
Arg3: 00000001, bitfield :
bit 0 : value 0 = read operation, 1 = write operation
bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: 820d0c1f, address which referenced memory

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


WRITE_ADDRESS: GetPointerFromAddress: unable to read from 82154868
Unable to read MiSystemVaType memory at 82134420
8cb5bcc0

CURRENT_IRQL:  1b

FAULTING_IP:
nt!KiUnwaitThread+19
820d0c1f 890a            mov     dword ptr [edx],ecx

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

BUGCHECK_STR:  0xA

PROCESS_NAME:  System

TRAP_FRAME:  821126c4 -- (.trap 0xffffffff821126c4)
ErrCode = 00000002
eax=85c5d4d8 ebx=00000000 ecx=8cb5bcc0 edx=8cb5bcc0 esi=85c5d420 edi=ed9c7048
eip=820d0c1f esp=82112738 ebp=8211274c iopl=0         nv up ei pl nz na pe nc
cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00010206
nt!KiUnwaitThread+0x19:
820d0c1f 890a            mov     dword ptr [edx],ecx  ds:0023:8cb5bcc0=????????
Resetting default scope

LAST_CONTROL_TRANSFER:  from 820d0c1f to 82077d24

STACK_TEXT:
821126c4 820d0c1f badb0d00 8cb5bcc0 87952ed0 nt!KiTrap0E+0x2ac
8211274c 8205f486 00000002 85c5d420 ed9c7048 nt!KiUnwaitThread+0x19
82112770 8205f52a ed9c7048 ed9c7008 00000000 nt!KiInsertQueueApc+0x2a0
82112790 8205742b ed9c7048 00000000 00000000 nt!KeInsertQueueApc+0x4b
821127c8 8f989cd0 e79e1e88 e79e1f70 00000000 nt!IopfCompleteRequest+0x438
821127e0 8a869ce7 00000007 00000000 00000007 tdx!TdxMessageTlRequestComplete+0x94
82112804 8a869d33 e79e1f70 e79e1e88 00000000 tcpip!UdpEndSendMessages+0xfa
8211281c 8a560c7f e79e1e88 00000001 00000000 tcpip!UdpSendMessagesDatagramsComplete+0x22
8211284c 8a86e0ab 00000000 00000000 889a0558 NETIO!NetioDereferenceNetBufferListChain+0xcf
82112860 8a6d341e 878689e8 e79e1e88 00000000 tcpip!FlSendNetBufferListChainComplete+0x1c
82112894 8a6084f1 86c440e8 e79e1e88 00000000 NDIS!ndisMSendCompleteNetBufferListsInternal+0xb8
821128a8 8fe3f0ee 87a092b0 e79e1e88 00000000 NDIS!NdisFSendNetBufferListsComplete+0x1a
821128cc 8a6084f1 87a07230 e79e1e88 00000000 pacer!PcFilterSendNetBufferListsComplete+0xba
821128e0 8fe516f7 88940c10 e79e1e88 00000000 NDIS!NdisFSendNetBufferListsComplete+0x1a
WARNING: Stack unwind information not available. Following frames may be wrong.
821128fc 8a6084f1 889a67a8 e79e1e88 00000000 SymIMv+0x16f7
82112910 91ab182f 889404e0 e79e1e88 00000000 NDIS!NdisFSendNetBufferListsComplete+0x1a
82112930 91aaf035 00000000 00000000 88939008 nwifi!MP6CancelSend+0x231
82112954 91ab064c 8893fc08 ed8e6080 00000000 nwifi!Dot11SendCompletion+0x2d
8211296c 8a6d34dd 8893fc08 ed8e6080 00000000 nwifi!Pt6SendComplete+0x1e
8211298c 8ee0ef66 86c440e8 ed8e6080 00000000 NDIS!NdisMSendNetBufferListsComplete+0x70
821129ac 8ee76a7e 86f6acb0 ed8e6080 00000000 NETw3v32+0x6f66
82112a10 8ee10e46 b347a4ff 86013be8 b347a478 NETw3v32+0x6ea7e
82112a38 8ee11061 87091ee0 86f6acb0 82112a64 NETw3v32+0x8e46
82112a48 8ee10c77 86013be8 86183fc0 89533a30 NETw3v32+0x9061
82112a64 8ee71ba2 86f6acb0 000000cd 00000000 NETw3v32+0x8c77
82112a8c 8ee1d623 86f6acb0 b347a478 00000000 NETw3v32+0x69ba2
82112aa0 8ee2f945 872261c8 b347a478 00000000 NETw3v32+0x15623
82112b04 8ee10e46 87600b58 89beaa20 89533a30 NETw3v32+0x27945
82112b2c 8ee11061 86f6f0d8 872261c8 82112b58 NETw3v32+0x8e46
82112b3c 8ee10c77 89beaa20 8655dfb8 89533a64 NETw3v32+0x9061
82112b58 8ee38bc6 872261c8 0000009d 00000000 NETw3v32+0x8c77
82112ba8 8ee1a0b1 8771b000 874a1004 86f37e9c NETw3v32+0x30bc6
82112bd0 8ee1c082 02dd9e68 874a1004 00000000 NETw3v32+0x120b1
82112c10 8ee1c30b 87229ea0 8729c540 00000041 NETw3v32+0x14082
82112c50 8ee1879a 87229ea0 8729c540 000000ff NETw3v32+0x1430b
82112c80 8ee16a89 872b4e01 8729c540 82112c9c NETw3v32+0x1079a
82112c90 8ee094a5 8729c540 82112cc4 8a6c5115 NETw3v32+0xea89
82112c9c 8a6c5115 87079110 00000000 00000000 NETw3v32+0x14a5
82112cc4 8a606468 873ffe18 8ee09490 00000000 NDIS!ndisMiniportDpc+0x7a
82112ce8 820d3450 873ffe18 86c440e8 00000000 NDIS!ndisInterruptDpc+0xc4
82112d50 820d1edd 00000000 0000000e 00000000 nt!KiRetireDpcList+0x147
82112d54 00000000 0000000e 00000000 00000000 nt!KiIdleLoop+0x49

STACK_COMMAND:  kb

FOLLOWUP_IP:
tdx!TdxMessageTlRequestComplete+94
8f989cd0 6804010000      push    104h

SYMBOL_STACK_INDEX:  5

SYMBOL_NAME:  tdx!TdxMessageTlRequestComplete+94

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: tdx

IMAGE_NAME:  tdx.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  479190ee

FAILURE_BUCKET_ID:  0xA_tdx!TdxMessageTlRequestComplete+94

BUCKET_ID:  0xA_tdx!TdxMessageTlRequestComplete+94

Followup: MachineOwner

It looks like a bunch of hieroglyphic mumbo jumbo. However, if you look closely you can gain some further insight into the possible problem or cause of it. The PROCESS_NAME is System suggesting a system process. The MODULE_NAME is tdx.

OUTPUT KD COMMAND: LMVM TDX

The tdx was clickable for me which executes the command:
kd> lmvm tdx

as a kd command. The 'lm' in "lmvm" is Loaded Module. The 'v' is Verbose. The 'm' is a pattern match. From the debugger chm manual it states it as:

m Pattern
Specifies a pattern that the module name must match. Pattern can contain a variety of wildcard characters and specifiers. For more information about the syntax of this information, see String Wildcard Syntax.

You can find a lot of information from the chm manual when you download the windbg from Microsoft. It will located here:
C:Program FilesDebugging Tools for Windows (x86)debugger.chm

The output from the above command is:
0: kd> lmvm tdx
start    end        module name
8f97f000 8f995000   tdx        (pdb symbols)          c:Program FilesDebugging Tools for Windows (x86)symtdx.pdbCFB0726BF9864FDDA4B793D5E641E5531tdx.pdb
Loaded symbol image file: tdx.sys
Mapped memory image file: c:Program FilesDebugging Tools for Windows (x86)symtdx.sys479190EE16000tdx.sys
Image path: SystemRootsystem32DRIVERStdx.sys
Image name: tdx.sys
Timestamp:        Fri Jan 18 21:55:58 2008 (479190EE)
CheckSum:         0001391F
ImageSize:        00016000
File version:     6.0.6001.18000
Product version:  6.0.6001.18000
File flags:       0 (Mask 3F)
File OS:          40004 NT Win32
File type:        3.6 Driver
File date:        00000000.00000000
Translations:     0409.04b0
CompanyName:      Microsoft Corporation
ProductName:      Microsoft® Windows® Operating System
InternalName:     tdx.sys
OriginalFilename: tdx.sys
ProductVersion:   6.0.6001.18000
FileVersion:      6.0.6001.18000 (longhorn_rtm.080118-1840)
FileDescription:  TDI Translation Driver
LegalCopyright:   © Microsoft Corporation. All rights reserved.

So we glean some more insight. Who makes the module and the possible cause of the problem.

I look at the STACK_TEXT and there are references to tcpip and NETIO which seems to allude to a network problem. So I googled others with a BSOD and tdx.sys problem and there is a hotfix for this problem. However, a BIG word of caution please do not download the hotfix if this particular problem does not apply to you. Microsoft suggests to use the Microsoft Update procedures which will include all hotfixes.

To obtain the link to the hotfix for the network problem Google "Hotfix 934611 microsoft".

I did not download this hotfix but rather opted to updated my service pack. Currently, Vista is at Service Pack 2. I only had Service Pack 1. So I'll see if this fixes the problem.

To check what Service Pack you have installed and what bit version (32-bit or 64-bit) go to:

"Start/Computer". Right-click "Computer" and then click "Properties". You'll see the Service Pack information under the heading "Windows Edition". Under the heading "System" (around mid-way through the page) you'll see "System type:" which will display whether you have 32-bit or 64-bit versions installed.

To obtain the Service Pack 2 for Vista Google "sp2 vista microsoft".