printing stack trace for windows coredump without needing to enter windbg/visual studio interactively

Question

I would like to get a stack trace of thread which is causing the crash by invoking predefined commands written in a script, so that I run script and I get a log file containing the back trace of all threads. I can then parse this log file to see if there is known issue.

Mazurek

Answer 1

I'd recommend you take a look a cdb. It's a pretty full-featured commandline version of windbg and should already be installed with windbg.

You could tell it to open the dump, print the stack traces and exit with the command line:

cdb -z yourdump.dmp -c "~*kv; q"

Or you could even get fancy and do some automated analysis with:

cdb -z yourdump.dmp -c "!analyze -v; q"

This probably makes more sense since it will try to recover the stack at the time a second chance exception was thrown, where just printing the stacks with k would miss the issue entirely. You could also make use of the FAILURE_BUCKET_ID it outputs to do most of the categorization for you.

From there, it is a just a matter of using before the command you wish to execute .logopen or redirecting the commandline output to a file.

Antonietta

Answer 2

You can run WinDbg or Cdb with the -z option to open the dump, -c to execute commands, -log to dump the output into a file and -y to set up the symbol path.

To run a script from a file, try one of the $<, $><, $$<, $$>< or $$>a< for the command. Read the WinDbg help file about the differences between those.

Usually not relevant, but for completeness: note that some commands are not scriptable (MSDN).

Outrange

Answer 3

If the Dump is a Full Kernel memory Dump (default 64 kb Mini Dumps (xp-sp3 size) do not have sufficient information on thread stacks )

thats if you have set In mycomputers -> properties->advanced -> startup and recovery -> complete memory dump )

verifiable with

F:\>reg query hklm\system\currentcontrolset\control\crashcontrol /v DumpFile

! REG.EXE VERSION 3.0

HKEY_LOCAL_MACHINE\system\currentcontrolset\control\crashcontrol
    DumpFile    REG_EXPAND_SZ   %SystemRoot%\MEMORY.DMP

F:>

you can use !for_each_thread @#Thread to dump stack traces of all threads

the example below is from an xp-sp3 vm configured to write a complete memory dump on blue screen attached to kd in host

i issue .crash and crash the vm

kd> .crash
Shutdown occurred at (Tue Jul  8 11:10:51.421 2014 (UTC + 5:30))...unloading all symbol tables.
Waiting to reconnect...

on rebooting the target writes MEMORY.DMP which i copy to host shared folder (can do in target also but this vm does not have windbg installed in target so copied to host)

and i run this command

F:\>cdb -c ".logopen c:\\foost.txt;!for_each_thread !thread @#Thread 16; .logclo
se;q" -z c:\sharedwithvm\MEMORY.DMP

this opens each thread in the dump sets the proper process context and dumps the stack info to a file and quits (can take several minutes/hours based on the dump size)

the vm had 302 thread running when it was crashed stack traces for all 302 threads stored in c:\foost.txt

C:\>cdb -c ".shell -ci \"!for_each_thread .echo @#Thread ;q\" wc -l" -z c:\share
dwithvm\MEMORY.DMP | grep -A 1 Reading
kd> cdb: Reading initial command '.shell -ci "!for_each_thread .echo @#Thread ;q
" wc -l'
303 <---------------

C:\>grep ChildEBP foost.txt | wc -l
302  <---------------------

C:\>

Villager

Is it you, blabb? Irritates me a bit. – Outrange

It was just the effect that it somehow seemed you lost all your reputation. Do you use another account? I wonder why: you just gained some useful privileges and now you start from scratch again? With 11 reputation I can`t even invite you to a chat. – Outrange