Wanting to learn to read dump files

Status
Not open for further replies.
Hey all, I was working on a thread yesterday where a user posted some dump files about random BSOD's he was getting. Someone else following the thread was able to analyze the dumps and totally nailed what was causing the BSOD issues.

I'm just wondering what the best way to analyze these dumps are. I played around with bluescreenview for a while but was unable to skillfully come to the conclusion this other user did. Here's a link to the thread...
http://www.tomshardware.com/answers/id-2814190/bsod-page-fault-nonpaged-area-ntoskrnl-exe.html
 
Solution
after you get the debugger installed, you want to set up a path to the microsoft symbol server.
start windbg.exe then hit control+s
and paste in the symbol path below:
http://msdl.microsoft.com/download/symbols

save the workspace and you will have symbols when you look at a crash dump.

you will want to google "windbg cheat sheet"
to help you find some of the common commands.
each type of memory dump will contain different types of info, and allow different commands to work in the debugger.

for example: a mini dump, will contain the stack trace, basic info about the machine, and the list of drivers installed

a kernel dump will contain all of the loaded drivers in memory, all of their stack traces, basically all of the kernel mode...
First off you'll want to download WinDbg from the Windows 8.1 SDK. Here: https://www.microsoft.com/click/services/Redirect2.ashx?CR_EAC=300135395

During the SDK installation when it asks you what feautures you want to download, unselect everything except "Debugging Tools for Windows". After you finish installing the debugging tools. Open up WinDbg (X64) or WinDbg (X86) depending on your OS.

Then go to http://www.techrepublic.com/blog/windows-and-office/how-do-i-use-windbg-debugger-to-troubleshoot-a-blue-screen-of-death/ and scroll down to "Setting Up and Using WinDBG" and follow the steps.
 


I appreciate that answer, do you know if WinDbg from the Windows 8.1 SDK. work for Windows 7 and 10 dumps as well?
 


I can't say for Windows 7 as I haven't it tried it, but I've been using it on Windows 10 for a few weeks now without any issues.

EDIT: There's actually an updated version for Windows 10 https://dev.windows.com/en-us/downloads/windows-10-sdk. Use the same install directions as the Windows 8.1 installation.
 
after you get the debugger installed, you want to set up a path to the microsoft symbol server.
start windbg.exe then hit control+s
and paste in the symbol path below:
http://msdl.microsoft.com/download/symbols

save the workspace and you will have symbols when you look at a crash dump.

you will want to google "windbg cheat sheet"
to help you find some of the common commands.
each type of memory dump will contain different types of info, and allow different commands to work in the debugger.

for example: a mini dump, will contain the stack trace, basic info about the machine, and the list of drivers installed

a kernel dump will contain all of the loaded drivers in memory, all of their stack traces, basically all of the kernel mode driver info.
a bunch of internal memory logs but no user mode/application info.

The kernel dump does allow a lot more of the automated debugging commands to be used, It is often required to figure out USB problems, plug and play problems, problems where the system "hangs", power management problems.

a full memory dump basically contains a copy of what was loaded in memory at the time of the crash.
very useful when trying to figure out how a virus works or if you really really want to know why something is failing and trace if all the way from a application to a bugcheck.


here are some that are useful:
lmiftsm ; this will show what drivers are loaded, listed in alphabetical order.
if you see a module you do not recognize you can look here: http://www.carrona.org/dvrref.php

!for_each_module !chkimg @#ModuleName ; this will check each module for corruption of the module in memory
any non microsoft module will show a error, very useful to use before you start debugging. it will also help you by showing which modules have been hacked/corrupted or are from a 3rd party.

!sysinfo smbios

this will dump the BIOS info about the machine, it will also show the CPU, the CPU speed and the memory info about the machine.


!error "error code" will look up error codes for you. useful because the error codes are kind of scrunched up in bit patterns in the error code.

kv command, will show the stack trace, top of the list is the most recent system calls.
you can see the system calls and kind of figure out what subsystem they came from by working down the list.
the calls have abbreviation for the subsystems here is a list of most of them: (it is a list i pasted from some other location on the internet, maybe from http://www.osronline.com/article.cfm?article=589 (at least in my notes)

Adtp (no public functions): auditing module. Private to the security reference monitor (which I will call the security module).
Ael: application compatibility executable cache module. Used by the application compatibility module.
Alpc/Alpcp: asynchronous LPC (ALPC) module. A redesign of LPC from earlier kernel versions.
AnFw: background fader module. Used by the boot background module.
Apphelp/Apphelp: application compatibility module.
Arb/Arbp: memory arbiter module. Used by I/O and memory module.
AuthzBasep: authz module for Win32.
Bapdp: boot application data module. Used by the boot module.
Bcd: boot configuration module (boot manager).
Bg/Bgk/Bgp: boot background module. Used in Windows 7 for high-res booting - displays the Windows logo.
Bi: EFI boot module?
Cc: cache module.
Clfs: common log file system module.
Cm/Cmp: configuration manager module (the registry).
Dbg/Dbgk/Dbgkp: debugging module.
Em: ???
Etw/Etwp: event tracing module.
Ex/Exp: executive module.
FsRtl/FsRtlp: file system run-time library module.
Hv/Hvp: hive management module. Private to the configuration manager module.
Hvl/Hvlp: hardware virtualization module.
Io/Iop: I/O manager module.
Kd/Kdp: kernel-mode debugging module.
Ke/Ki: kernel module.
Ldr/Ldrp: loader module. Supports resource loading.
Lpc/Lpcp: LPC module. Replaced by ALPC from Vista.
Mm/Mi: memory manager module.
Nt: system calls.
Ob/Obp: object manager module.
Pf/Pfp: prefetching module.
Pnp: plug and play module.
Po/Pop: power management module.
Pp/Pi: hardware profiles?
Ps/Psp: process manager module.
Rtl/Rtlp: run-time library module.
Sdb/Sdbp: apphelp database module.
Se/Sep: security module.
Tm/Tmp: transaction manager module.
Verifier/Vf/Vi: driver verifier module.
Wmi/Wmip: WMI module.
Zw: system calls.

For what it's worth, page 73 of Windows Internals 5th Ed. documents the Pp prefix:
Pp PnP manager
The Pi prefix does not appear in the list, though.
From the same source, some additions /modifications to your list
Em = Errata manager
Hal = Hardware abstraction layer
Hvl = Hypervisor Library
Kd = Kernel debugger
Lsa = Local Security Authority
Nt = NT system services
Pp = internal functions of PnP manager
Whea = Windows Hardware Error Architecture
Wdi = Windows Diagnostic Infrastructure


Bi : internal functions of Bcd ?
Pi : internal functions of PnP manager





 
Solution
Status
Not open for further replies.