How to debug/read minidump(bSOD) using windbg

[wingleaf]

Hey guys,

Please tell me on how to debug/read minidump(BSOD) using windbg to troubleshoot PC. any site, tutorials would be appreciated

I really want to know why others know what is the problem in BSOD while reading the minidump like this for example http://www.techspot.com/vb/all/windows/t-4..._not_equal.html

this is the sample of the minidump based on my pc, can you please debug it and please tell me step by step on how to know the problem.

Microsoft ® Windows Debugger Version 6.6.0007.5

Copyright © Microsoft Corporation. All rights reserved.

Loading Dump File [C:\WINDOWS\Minidump\Mini021507-01.dmp]

Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: *** Invalid ***

****************************************************************************

* Symbol loading may be unreliable without a symbol search path. *

* Use .symfix to have the debugger choose a symbol path. *

* After setting your symbol path, use .reload to refresh symbol locations. *

****************************************************************************

Executable search path is:

*********************************************************************

* Symbols can not be loaded because symbol path is not initialized. *

* *

* The Symbol Path can be set by: *

* using the _NT_SYMBOL_PATH environment variable. *

* using the -y <symbol_path> argument when starting the debugger. *

* using .sympath and .sympath+ *

*********************************************************************

Unable to load image ntoskrnl.exe, Win32 error 2

*** WARNING: Unable to verify timestamp for ntoskrnl.exe

*** ERROR: Module load completed but symbols could not be loaded for ntoskrnl.exe

Windows XP Kernel Version 2600 (Service Pack 2) UP Free x86 compatible

Product: WinNt, suite: TerminalServer SingleUserTS

Kernel base = 0x804d7000 PsLoadedModuleList = 0x8055a420

Debug session time: Thu Feb 15 04:47:23.281 2007 (GMT+8)

System Uptime: 0 days 5:50:38.833

*********************************************************************

* Symbols can not be loaded because symbol path is not initialized. *

* *

* The Symbol Path can be set by: *

* using the _NT_SYMBOL_PATH environment variable. *

* using the -y <symbol_path> argument when starting the debugger. *

* using .sympath and .sympath+ *

*********************************************************************

Unable to load image ntoskrnl.exe, Win32 error 2

*** WARNING: Unable to verify timestamp for ntoskrnl.exe

*** ERROR: Module load completed but symbols could not be loaded for ntoskrnl.exe

Loading Kernel Symbols

....................................................................................................

..................

Loading User Symbols

Loading unloaded module list

..............

*******************************************************************************

* *

* Bugcheck Analysis *

* *

*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 1000000A, {28, 2, 0, 804f0bbc}

ANALYSIS: Kernel with unknown size. Will force reload symbols with known size.

ANALYSIS: Force reload command: .reload /f ntoskrnl.exe=FFFFFFFF804D7000,213F80,42250FF9

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

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

Probably caused by : ntoskrnl.exe ( nt+19bbc )

Followup: MachineOwner

---------

Thanks,

gau

[cluberti]

Well, considering you don't even have a valid symbol path set, you aren't going to get far with this dump, and it tells me something about where you should start if this is a path you do really want to travel.

Consider reading this post on the Ask the Performance Team blog on how to get started with understanding the innards of how Windows works, because without this knowledge your debugging skills will be lacking. Another thing you really need to know, even if just on a basic level, is the C programming language - the OS and almost all of the call stacks you'll see in a dump are C code, and if you don't understand C at a functional level, you'll be a poor debugger. The last suggestion would be to try and go to a user-mode or kernel-mode debugging class (or both) given by your local training center if possible, as this is a very good way to go from a basic debugger to one with some more-than-basic knowledge. Once you've done the above, you'll be ready to dive into some really interesting memory dumps and learn more, to become a fairly good debugger - and over the course of a few years, you'll get even better from there if you do it very regularly.

Debugging does have some science, but there's also an art to it that just can't be easily taught in one or two threads on how to troubleshoot a STOP 0x1a, or any other crash or manually-generated dump.

By the way, configure your machine for a full dump, as minidumps are pretty useless. If you do want to actually troubleshoot the STOP 0x1A you're seeing here, you'll need at least a kernel dump the next time it occurs, and if disk space isn't an issue, it never, ever hurts to get a complete dump of any issue just in case.