Retrieve callstack of Windows Minidump file

Question

I have a minidump file from a crashing application on windows system at a customer.

We like to know:

• Which application crashed
• What function threw the exception
• Line number if available (Just for early crash envestigation)

What I'm trying to prevent is to setup a complete environment just to get a function (environment with dll and PDB is several gigabytes I don't want to copy around).

Is it possible to just have the minidump and get the function using scripting/tooling?

If I open the dump with VS2017 the callstack shows KERNELBASE.DLL and a enter code hereDLL of us. If I load the symbols of that DLL+PDB I see the function name. Now I want to automate that, how do I know which DLL/PDB is required beforehand?

So I tried with cdb

cdb.exe -y SRVc:\symbolshttp://msdl.microsoft.com/download/symbols -z myDmp.dmp -c ".lines; !analyze -v ; q"

And it spits out a lot of info, and at the end it shows MODULE_NAME which is the failing DLL. (No actual function name)

MODULE_NAME: MyDLL 
FAILURE_BUCKET_ID:  APPLICATION_FAULT_e1000003_MyDLL.dll!Unknown

If I put the MyDLL.DLL and MyDLL.PDB in the same folder as the minidump and rerun the command it shows:

MODULE_NAME: MyDLL 
FAILURE_BUCKET_ID: APPLICATION_FAULT_e1000003_MyDLL.dll!MyFancyClass::MyCrashingFunction 
FAULTING_SOURCE_LINE:  c:\somepath.cpp 
FAULTING_SOURCE_LINE_NUMBER:  123

Is this the way to go? As in,

1. parse the output and find module_name
2. put DLL and PDB in same folder
3. rerun in the hope to get more information?

Do I always get the correct crash? Because without dll/dbg initially I also see a

WARNING: Stack unwind information not available. Following frames may be wrong.

Answer 1

Is it possible to just have the minidump and get the function using scripting/tooling?

No. As you said yourself, you need a complete environment with PDBs.

how do I know which DLL/PDB is required beforehand?

You don't know that. However, you can store all the PDBs you ever generated, so you have them available when needed. In order to store all those PDBs, you need a n-tier symbol store, not a flat directory full of files. The utility you need is symstore.exe. Don't confuse a symbol store with a symbol server. You don't necessarily need a symbol server; it could be a local directory. However, a symbol server may have additional advantages, especially if you need to go into deeper analysis later from a different PC.

Is this the way to go?

I think there are simpler ways than parsing that output of !analyze -v.

Which application crashed

Try the pipe |. It should give you the full path and name of the executable.

What function threw the exception

The k command should already do that, given the correct context is set.

Line number if available

Should already be part of the callstack k if symbols are configured correctly (yours and Microsoft's).

Usually you also want to know the type of the exception, so add .exr -1 to your script.

If you want to output the text of the commands for parsing with an external tool, look into .logopen.

Do I always get the correct crash?

You may still see warnings about DLLs that cannot be found. Those may be hooks or 3rd party DLLs for which neither you nor Microsoft have PDB files.