This is a tutorial on how to configure and read your minidump files when you receive a BSOD (Blue Screen of Death) in order to better understand the cause of the problem. The first thing is the first. Download the latest debugging tools from the Microsoft site.
Then go to Start / Launch search. Type i
the command cmd.
Then change the directories to:
C: Program Files Debugging Tools for Windows (x86)
using the command:
cd c: program file debugging tools for windows (x86)
It is case insensitive when using the CD order.
Then type:
windbg.exe zc: windowsminidumpmini06190901.dmp c "! analyze v"
Your minidump file is located in C: WindowsMinidumpMini06200901.dmp. It will be in the form "MiniMMDDYY01.dmp".
CORE SYMBOLS ARE WRONG. PLEASE ATTACH SYMBOLS TO MAKE ANALYSIS
If somewhere in the output of the bug check scan you see an error like:
The core symbols are FALSE. Please attach symbols to do the analysis.
Then there is a good chance that you are using previous and incompatible symbols or corrupted files or you do not have the correct symbols in the specified location when the Windbg program tried to parse the minidump file. So what I did was open the Windbg program located at C: Program Files Debugging Tools for Windows (x86) (under Vista and I believe it is the same location for XP).
SETTING THE PATH OF THE SYMBOL FILE VIA THE WINDBG COMMAND LINE:
This is an important step, so make sure your symbol path file is set correctly, lest the kernel symbols be bad error or other types of errors. Now set the symbol file path (file path / symbol file) to:
SRVe: symbols[path to microsoft symbols path]
However, for some reason I have found that to set the symbol file path in the "File / Symbol Path" field, you cannot change it directly with the "File / Symbol Path" field. So what I found you need to change it through the Windbg command window by going to:
"Display / Control"
At the bottom of the command window next to the "kd>" prompt, type this:
.sympath SRVe: symbols[path to microsoft symbols path].
The part between the two asterisks () is where the symbols for Microsoft's servers will be downloaded. It's quite large (around 22MB), so make sure you have enough disk space.
SETTING THE SYMBOL FILE PATH IN THE VARIABLE ENVIRONMENT:
You can also set it in your environment variable in your system or user environment variable. To do this, click on the WINDOWS KEY + e. The WINDOWS KEY is the key to the right of the LEFT CTRL key on the keyboard. This will open Windows Explorer.
Then click on "Advanced system settings" at the top left of the window. This step only applies to Vista. For XP users, just click on the Advanced tab.
Then click on the "Environment variable" button 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:
symsrvsymsrv.dlle: symbols[path to microsoft symbols path]
If you set the symbol file path as a system environment variable I think you may need to restart your computer for it to take effect.
WINDBG COMMAND EXIT
So the following is the output of my crash:
Microsoft (R) Windows debugger version 6.11.0001.404 X86
Copyright (c) Microsoft Corporation. All rights reserved.
Loading the dump file [c:windowsminidumpmini06260901.dmp]
Mini Kernel Dump File: only registers and stack trace are available
The symbol search path is: SRVe: symbols[path to microsoft symbols]
The executable search path is:
Windows Server 2008 / Windows Vista Kernel Version 6001 (Service Pack 1) MP (2 procs) Compatible x86 free
Product: WinNt, suite: TerminalServer SingleUserTS Personal
Built by: 6001.18226.x86fre.vistasp1_gdr.0903021506
Machine name:
Kernel Base = 0x8201d000 PsLoadedModuleList = 0x82134c70
Debug session time: Fri Jun 26 16: 25: 11.288 2009 (GMT7)
System availability: 0 days 21: 39: 36.148
Loading kernel symbols
.................................................. .............
.................................................. ..............
.................................................. .........
Loading user symbols
Loading the list of unloaded modules
............................
Bugcheck analysis
Use! Analyze v for detailed debugging information.
Bug Check A, 8cb5bcc0, 1b, 1, 820d0c1f
Unable to load Image SystemRootsystem32DRIVERSSymIMv.sys, Win32 error 0n2
WARNING: Unable to verify timestamp for SymIMv.sys
ERROR: Module loading is complete 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 loading is complete but symbols could not be loaded for NETw3v32.sys
Processing of the initial order '! Analyze v '
Probably caused by: tdx.sys (tdx! TdxMessageTlRequestComplete + 94)
Tracking: 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 a
interrupt request level (IRQL) too high. It is generally
caused by drivers using incorrect addresses.
If a kernel debugger is available, get the stack trace.
Arguments:
Arg1: 8cb5bcc0, referenced memory
Arg2: 0000001b, IRQL
Arg3: 00000001, bit field:
bit 0: value 0 = read operation, 1 = write operation
bit 3: value 0 = not a run operation, 1 = run operation (only on chips supporting this state level)
Arg4: 820d0c1f, address which referenced the memory
Debugging Details:
WRITE_ADDRESS: GetPointerFromAddress: Could not read from 82154868
Failed 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: 4526c4 (.trap 0xffffffff4526c4)
ErrCode = 00000002
eax = 85c5d4d8 ebx = 00000000 ecx = 8cb5bcc0 edx = 8cb5bcc0 esi = 85c5d420 edi = ed9c7048
eip = 820d0c1f esp = 452738 ebp = 45274c 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 = ????????
Reset Default Scope
LAST_CONTROL_TRANSFER: from 820d0c1f to 82077d24
STACK_TEXT:
4526c4 820d0c1f badb0d00 8cb5bcc0 87952ed0 nt! KiTrap0E + 0x2ac
45274c 8205f486 00000002 85c5d420 ed9c7048 nt! KiUnwaitThread + 0x19
452770 8205f52a ed9c7048 ed9c7008 00000000 nt! KiInsertQueueApc + 0x2a0
452790 8205742b ed9c7048 00000000 00000000 nt! KeInsertQueueApc + 0x4b
4527c8 8f989cd0 e79e1e88 e79e1f70 00000000 nt! IopfCompleteRequest + 0x438
4527e0 8a869ce7 00000007 00000000 00000007 tdx! TdxMessageTlRequestComplete + 0x94
452804 8a869d33 e79e1f70 e79e1e88 00000000 tcpip! UdpEndSendMessages + 0xfa
45281c 8a560c7f e79e1e88 00000001 00000000 tcpip! UdpSendMessagesDatagramsComplete + 0x22
...
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
Tracking: MachineOwner
It looks like a bunch of hieroglyphic jumbo mumbo. However, if you look closely, you can gain additional insight into the possible problem or its cause. The PROCESS_NAME is a system suggesting a system process. The MODULE_NAME is tdx.
KD OUTPUT CONTROL: LMVM TDX
The tdx was clickable for me running the command:
kd> lmvm tdx
like a kd command. The 'lm' in "lmvm" is Loaded Module. The "v" is verbose. The "m" is a pattern match. In the chm debugger manual, it declares it as follows:
m Pattern
Specifies a template to match the module name. The pattern can contain a variety of wildcards and specifiers. For more information about the syntax of this information, see Wildcard String Syntax.
You can find a lot of information in the chm manual when you download the windbg from Microsoft. It will be located here:
C: Program Files Debugging Tools for Windows (x86) debugger.chm
The result of the above command is:
0: kd> lmvm tdx
start end module name
8f97f000 8f995000 tdx (PDB symbols) c: Program Files Debugging Tools for Windows (x86) symtdx.pdbCFB0726BF9864FDDA4B793D5E641E5531tdx.pdb
Loaded symbol image file: tdx.sys
Mapped memory dump file: c: Program Files Debugging 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
Image Size: 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
Company name: Microsoft Corporation
Product Name: Microsoft® Windows® Operating System
Internal name: tdx.sys
Original file name: tdx.sys
Product version: 6.0.6001.18000
File version: 6.0.6001.18000 (longhorn_rtm.0801181840)
File Description: TDI Translation Driver
Copyright: © Microsoft Corporation. All rights reserved.
So we glean a little more information. Who makes the module and the possible cause of the problem.
I'm looking at the STACK_TEXT and there are references to tcpip and NETIO that seem to hint at a network issue. So I googled the others with BSOD and tdx.sys issue and there is a fix for this issue. However, a big word of warning please do not download the fix if this particular issue does not apply to you. Microsoft suggests using Microsoft Update procedures which will include all fixes.
To get the link to the fix for the Google network problem "Hotfix 934611 microsoft".
I did not download this hotfix, but instead chose to update my service pack. Currently Vista is in Service Pack 2. I only had Service Pack 1. So I'll see if that fixes the problem.
To check which service pack you have installed and which bit version (32 bit or 64 bit) go to:
"Start / Computer". Right click on "Computer" and then click on "Properties". You will see the service pack information under "Windows Edition". Under the heading "System" (halfway down the page) you will see "System type:" which will show whether you have 32-bit or 64-bit versions installed.
To obtain Service Pack 2 for Vista Google "Microsoft Vista sp2".