Interpreting Stacks in Windows Minidumps

Question

As someone who is just starting to learn the intricacies of computer debugging, for the life of me, I can't understand how to read the Stack Text of a dump in Windbg. I've no idea of where to start on how to interpret them or how to go about it. Can anyone offer direction to this poor soul?

ie (the only dump I have on hand with me actually)

>b69dd8f0 bfa1e255 016d2fc0 89efc000 00000040 nv4_disp+0x48b94

b69dd8f4 016d2fc0 89efc000 00000040 00000006 nv4_disp+0x49255

b69dd8f8 89efc000 00000040 00000006 bfa1dcc0 0x16d2fc0

b69dd8fc 00000000 00000006 bfa1dcc0 e1e71018 0x89efc000

I know the problem is to do with the Nvidia display driver, but what I want to know is how to actually read the stack (eg, what is b69dd8f4?) :-[

Answer 1

First, you need to have the proper symbols configured. The symbols will allow you to match memory addresses to function names. In order to do this you have to create a local folder in your machine in which you will store a local cache of symbols (for example: C:\symbols). Then you need to specify the symbols server path. To do this just go to: File > Symbol File Path and type:

SRV*c:\symbols*http://msdl.microsoft.com/download/symbols

You can find more information on how to correctly configure the symbols here.

Once you have properly configured the Symbols server you can open the minidump from: File > Open Crash Dump.

Once the minidump is opened it will show you on the left side of the command line the thread that was executing when the dump was generated. If you want to see what this thread was executing type:

kpn 200

This might take some time the first you execute it since it has to download the necessary public Microsoft related symbols the first time. Once all the symbols are downloaded you'll get something like:

01 MODULE!CLASS.FUNCTIONNAME1(...)
02 MODULE!CLASS.FUNCTIONNAME2(...)
03 MODULE!CLASS.FUNCTIONNAME3(...)
04 MODULE!CLASS.FUNCTIONNAME4(...)

Where:

• THE FIRST NUMBER: Indicates the frame number
• MODULE: The DLL that contains the code
• CLASS: (Only on C++ code) will show you the class that contains the code
• FUNCTIONAME: The method that was called. If you have the correct symbols you will also see the parameters.

You might also see something like

01 MODULE!+989823

This indicates that you don't have the proper Symbol for this DLL and therefore you are only able to see the method offset.

So, what is a callstack?

Imagine you have this code:

void main()
{
  method1();
}

void method1()
{
  method2();
}

int method2()
{
  return 20/0;
}

In this code method2 basically will throw an Exception since we are trying to divide by 0 and this will cause the process to crash. If we got a minidump when this occurred we would see the following callstack:

01 MYDLL!method2()
02 MYDLL!method1()
03 MYDLL!main()

You can follow from this callstack that "main" called "method1" that then called "method2" and it failed.

In your case you've got this callstack (which I guess is the result of running "kb" command)

b69dd8f0 bfa1e255 016d2fc0 89efc000 00000040 nv4_disp+0x48b94
b69dd8f4 016d2fc0 89efc000 00000040 00000006 nv4_disp+0x49255
b69dd8f8 89efc000 00000040 00000006 bfa1dcc0 0x16d2fc0
b69dd8fc 00000000 00000006 bfa1dcc0 e1e71018 0x89efc000

The first column indicates the Child Frame Pointer, the second column indicates the Return address of the method that is executing, the next three columns show the first 3 parameters that were passed to the method, and the last part is the DLL name (nv4_disp) and the offset of the method that is being executed (+0x48b94). Since you don't have the symbols you are not able to see the method name. I doubt tha NVIDIA offers public access to their symbols so I gues you can't get much information from here.

I recommend you run "kpn 200". This will show you the full callstack and you might be able to see the origin of the method that caused this crash (if it was a Microsoft DLL you should have the proper symbols in the steps that I provided you).

At least you know it's related to a NVIDIA bug ;-) Try upgrading the DLLs of this driver to the latest version.

In case you want to learn more about WinDBG debugging I recommend the following links:

• If broken it is, fix it you should
• TechNet Webcast: Windows Hang and Crash Dump Analysis
• Delicious.com popular links on WinDBG

Answer 2

A really good tutorial on interpreting a stack trace is available here:

http://www.codeproject.com/KB/debug/cdbntsd2.aspx

However, even with a tutorial like that it can be very difficult (or near impossible) to interpret a stack dump without the proper symbols available/loaded.