Minidump Analysis (Part 1)

Small Memory Dumps, also referred as minidumps because they are stored in %SystemRoot% \ Minidump folder, contain only bugcheck information, kernel mode stack data and the list of loaded drivers. They can be used to transmit system crash information to a vendor or a 3rd-party for an automated crash dump analysis. Another use is to keep system crash history. In this part I discuss the scripting approach to extract information from all minidumps stored on a particular system. The script processes all minidump files and creates text log files containing the following information:

  1. Crash dump name and type 

  2. OS information, crash time and system uptime 

  3. Processor context (r) and verbose stack trace (kv) prior to applying !analyze -v. This is useful sometimes when WinDbg reconstructs a different stack trace after changing a processor context to the execution context at the time of a trap, exception or fault. 

  4. The output of !analyze -v command

  5. Processor context (r) and verbose stack trace (kv) after !analyze -v command.

  6. Code disassembly for the current execution pointer (EIP or x64 RIP). This includes forward (u) and backward (ub) disassembly, and we also try to disassemble the whole function (uf) which should succeed if we have symbol information

  7. Raw stack dump with symbol information (dps)

  8. The same raw stack data but interpreted as pointers to Unicode zero-terminated strings (dpu). Some pointers on the stack might point to local string buffers located on the same stack. This can be a slow operation and WinDbg might temporarily hang.

  9. The same raw stack data but interpreted as pointers to ASCII zero-terminated strings (dpa). This can be a slow operation and WinDbg might temporarily hang.

  10. Verbose information about loaded drivers (lmv)

  11. CPU, machine ID, machine-specific registers, and verbose SMBIOS information like motherboard and devices (!sysinfo)

Here is WinDbg script listing:

$$
$$ MiniDmp2Txt: Dump information from minidump into log
$$
.logopen /d /u
.echo "command> ||"
||
.echo "command> vertarget"
vertarget
.echo "command> r (before analysis)"
r
.echo "command> kv (before analysis)"
kv 100
.echo "command> !analyze -v"
!analyze -v
.echo "command> r"
r
.echo "command> kv"
kv 100
.echo "command> ub eip"
ub eip
.echo "command> u eip"
u eip
.echo "command> uf eip"
uf eip
.echo "command> dps esp-3000 esp+3000"
dps esp-3000 esp+3000
.echo "command> dpu esp-3000 esp+3000"
dpu esp-3000 esp+3000
.echo "command> dpa esp-3000 esp+3000"
dpa esp-3000 esp+3000
.echo "command> lmv"
lmv
.echo "command> !sysinfo cpuinfo"
!sysinfo cpuinfo
.echo "command> !sysinfo cpuspeed"
!sysinfo cpuspeed
.echo "command> !sysinfo cpumicrocode"
!sysinfo cpumicrocode
.echo "command> !sysinfo gbl"
!sysinfo gbl
.echo "command> !sysinfo machineid"
!sysinfo machineid
.echo "command> !sysinfo registers"
!sysinfo registers
.echo "command> !sysinfo smbios -v"
!sysinfo smbios -v
.logclose
$$
$$ MiniDmp2Txt: End of File
$$

To run WinDbg automatically against each minidump file (.dmp) use the following VB script (customize symbol search path (-y) to point to your own folders):

'
' MiniDumps2Txt.vbs
'
Set fso = CreateObject("Scripting.FileSystemObject")
Set Folder = fso.GetFolder(".")
Set Files = Folder.Files
Set WshShell = CreateObject("WScript.Shell")
For Each File In Files
  If Mid(File.Name,Len(File.Name)-3,4) = ".dmp" Then
    Set oExec = WshShell.Exec("C:\Program Files\Debugging Tools for Windows\WinDbg.exe -y ""srv*c:\ms*http://msdl.microsoft.com/download/symbols"" -z " + File.Name + " -c ""$$><c:\scripts\MiniDmp2Txt.txt;q"" -Q -QS -QY -QSY")
    Do While oExec.Status = 0
      WScript.Sleep 1000
    Loop
  End If
Next
'
' MiniDumps2Txt.vbs: End of File
'

We can also use kd.exe instead of WinDbg but its window will be hidden if we use the same VB script.

Log file interpretation is the subject of the next minidump analysis part.

- Dmitry Vostokov @ DumpAnalysis.org -

6 Responses to “Minidump Analysis (Part 1)”

  1. Dmitry Vostokov Says:

    2nd part:

    http://www.dumpanalysis.org/blog/index.php/2007/09/06/minidump-analysis-part-2/

  2. zagadeesh Says:

    Dmitry,

    Why can’t we add some more snippets like
    get.reg HKLM\System\CurrentControlSet\Control\CrashControl\CrashDumpEnabled.
    if DWORD=1 Then Complete Memory Dump
    if DWORD=2 Then Kernel
    if DWORD=3 Then small memory dump.
    and also “DumpFile” Reg_EXPAND_SZ which will gives us any modification in path.
    We can analyzed other than small memory dump upto certain extent.

    Thanks

  3. Alex Says:

    Dmitry,

    I am new to Memory dump analysis and purchased your highly reccommended book “Memory Dump Analysis Volume1″. Unfortunately I coldn’t figure out what to do with this script. Should it be saved in specific location? How do you point it to the correct dump? Would you be able to provide more detailed instructions on running it?

    Greatly appreciate your help, Alex

  4. Dmitry Vostokov Says:

    Alex,

    Yes, both scripts should be saved. You can either have VBS script in the folder where you have dumps or modify this line:

    Set Folder = fso.GetFolder(”.”)

    If you are new to analysis then you probably should first try to load a dump file into WinDbg and run commands from MiniDmp2Txt manually just to see how they work. WinDbg.org has quick links to Debugging Tools and also MS and Citrix symbol locations to specify in Symbol File Path in WinDbg.

    Thanks,
    Dmitry

  5. Wisdom-Fu: E-mail alert when you find a memory dump « Wag the Real Says:

    […] Minidump Analysis (Part 1) […]

  6. Announcing the Auto Mini-Dump Analyser | chentiangemalc Says:

    […] http://www.dumpanalysis.org/blog/index.php/2007/08/29/minidump-analysis-part-1/ […]

Leave a Reply

You must be logged in to post a comment.