This is a tutorial on how to set up and read your minidump files when you get a BSOD (Blue Screen of Death) to gain further insight into the cause of the problem. The first is the first. Download the latest debugging tools from the Microsoft website.
Then go to Start/Start Search. Type I
the command cmd.
Then change directories:
C:Program FilesDebugging Tools for Windows (x86)
with the command:
cd c:Program Files Debugging Tools for Windows (x86)
The use of is not case-sensitive CD Command.
Then enter:
windbg.exe zc:windowsminidumpmini06190901.dmp c “!analyse v”
Your minidump file is located at C:WindowsMinidumpMini06200901.dmp. It has the form “MiniMMTTTJ01.dmp”.
CORE SYMBOLS ARE WRONG. PLEASE FIX ICONS TO PERFORM AN ANALYSIS
If you see an error somewhere in the bugcheck analysis output like:
Kernel symbols are WRONG. Please correct the symbols to perform the analysis.
Then most likely you are using previous and incompatible icons or corrupted files or you don’t have the right icons in the specified place when the Windbg program tried to analyze the minidump file. So I opened 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 ICON FILE PATH VIA THE WINDBG COMMAND LINE:
This is an important step, so make sure your symbol path file is set correctly so you don’t get the “kernel symbols are WRONG” error or other types of errors. Now set the icon file path (file/icon file path) to:
SRVe:Icons[path to microsoft symbols path]
However, for some reason I found that you can’t directly change the icon file path in the File/Icon File Path field using the File/Icon File Path field to set it. So I found that you need to change it from the Windbg command window by going to:
“View/Command”
At the bottom of the command window, next to the kd> prompt, type:
.sympath SRVe:symbols[path to microsoft symbols path].
In the part between the two asterisks () the symbols are downloaded from Microsoft’s servers. It’s quite large (around 22MB) so make sure you have enough storage space.
SET ICON FILE PATH IN ENVIRONMENT VARIABLE:
Alternatively you can set it in your environment variable in either 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 CONTROL key on the keyboard. This opens Windows Explorer.
Then click on “Advanced system settings” in the top left of the window. This step applies to Vista only. For XP users, just click on the Advanced tab.
Then click the “Environment Variable” button at the bottom of the window.
Then click the “New” button under System Variables. Again, you can create the environment as a user environment variable instead.
Under Variable Name, enter the following:
_NT_SYMBOL_PATH
In the Variable Value field, enter the following:
symsrvsymsrv.dlle:icons[path to microsoft symbols path]
If you set the icon file path as a system environment variable, you may need to restart your computer 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.
Dump file is loaded [c:windowsminidumpmini06260901.dmp]
Mini kernel dump file: Only registers and stack trace are available
Symbol search path is: SRVe:symbols[path to microsoft symbols]
Executable search path is:
Windows Server 2008/Windows Vista Kernel Version 6001 (Service Pack 1) MP (2 processors) Free x86 compatible
Product: WinNt, Suite: TerminalServer SingleUserTS Personal
Created by: 6001.18226.x86fre.vistasp1_gdr.0903021506
machine name:
Kernel Base = 0x8201d000 PsLoadedModuleList = 0x82134c70
Debug session time: Friday, June 26 16:25:11.288 2009 (GMT7)
System uptime: 0 days 21:39:36.148
Loading kernel symbols
………………………………………….. .. ………….
………………………………………….. .. …………..
………………………………………….. .. ………
Load user icons
Load the unloaded module list
……………………..
Bugcheck analysis
Use !analyze v for detailed debugging information.
Error check A, {8cb5bcc0, 1b, 1, 820d0c1f}
Image Cannot load SystemRootsystem32DRIVERSSymIMv.sys, Win32 error 0n2
WARNING: The timestamp for SymIMv.sys cannot be verified
ERROR: Module loading completed but failed to load symbols for SymIMv.sys
Image Cannot load SystemRootsystem32DRIVERSNETw3v32.sys, Win32 error 0n2
WARNING: The timestamp for NETw3v32.sys cannot be verified
ERROR: Module loading completed but failed to load symbols for NETw3v32.sys
Processing the initial command ‘!analyze v’
Probably caused by: tdx.sys ( tdx!TdxMessageTlRequestComplete+94 )
Addendum: machine owner
0: kd> !analysis 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) is too high. This is usually
caused by drivers using wrong addresses.
If a kernel debugger is available, get the stack backtrace.
arguments:
Arg1: 8cb5bcc0, memory referenced
Arg2: 0000001b, IRQL
Arg3: 00000001, bit field:
Bit 0: value 0 = read operation, 1 = write operation
Bit 3: value 0 = no execute operation, 1 = execute operation (only on chips that support this status level)
Arg4: 820d0c1f, address that referenced memory
Debugging Details:
WRITE_ADDRESS: GetPointerFromAddress: Unable to read 82154868
Unable to read MiSystemVaType memory at 82134420
8cb5bcc0
CURRENT_IRQL: 1b
BAD_IP:
nt!KiUnwaitThread+19
820d0c1f 890a mov dword ptr [edx]etc
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
BUGCHECK_STR: 0xA
PROCESS_NAME: System
TRAP_FRAME: 4526c4 (.trap 0xffffffff4526c4)
Error Code = 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],ecxds:0023:8cb5bcc0=?????????
Reset the default range
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: Machine owner
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
Addendum: machine owner
It looks like a bunch of hieroglyph mumbo-jumbo. However, if you look closely, you can gain more insight into the possible problem or the cause of it. The PROCESS_NAME is system and suggests a system process. The MODULE_NAME is tdx.
OUTPUT KD COMMAND: LMVM TDX
The tdx was clickable for me, which runs the command:
kd> lmvm tdx
as 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 says:
m pattern
Specifies a pattern that the module name must match. The pattern can contain a variety of wildcard characters and identifiers. For more information on the syntax of this information, see String wildcard syntax.
You can find a lot of information in the chm manual if you download the windbg from Microsoft. It is located here:
C:Program FilesDebugging Tools for Windows (x86)debugger.chm
The output of 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 icon image file: tdx.sys
Associated dump file: c:Program FilesDebugging Tools for Windows (x86)symtdx.sys479190EE16000tdx.sys
Image path: SystemRootsystem32DRIVERStdx.sys
Image name: tdx.sys
Timestamp: Friday January 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
Legal NoticeCopyright: © Microsoft Corporation. All rights reserved.
So we gain even more insight. Manufacturer of the module and possible cause of the problem.
I look at the STACK_TEXT and there are references to tcpip and NETIO which seems to indicate a network problem. So I googled others with a BSOD and tdx.sys issue and there is a hotfix for this issue. A big word of caution: do not download the hotfix if this particular issue does not apply to you. Microsoft suggests using the Microsoft Update procedures, which include all hotfixes.
To get the link to the hotfix for the network issue, Google “Hotfix 934611 Microsoft”.
I did not download this hotfix but decided to update my service pack. Currently Vista is on 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) you have, go to:
“Startup/Computer”. Right-click Computer and then click Properties. You’ll see the Service Pack information under the Windows Edition heading. Under the “System” heading (about halfway down the page) you’ll see “System type:” which indicates whether you have 32-bit or 64-bit versions installed.
How to get Service Pack 2 for Vista from Google “sp2 Vista Microsoft”.
Thanks to Victor Kimura | #Windbg #Minidump #Tutorial #Setting #reading #minidump #files
