0

I am debugging a program using WinDbg.

At the crash site, the last two frames of call stack are:

ChildEBP RetAddr  
WARNING: Stack unwind information not available. Following frames may be wrong.
0251bfe8 6031f8da npdf!ProvideCoreHFT2+0x24db0
0251c000 011eb7a5 npdf!ProvideCoreHFT2+0x5ac1a
...

I want to find out how frame 1 calls frame 0. Since the return address of frame 0 is 6031f8da, I opened the disassembly window and jump to that location, the code are:

...
6031f8d5 e8a6d0ffff      call    npdf!ProvideCoreHFT2+0x57cc0 (6031c980)
6031f8da 5f              pop     edi
...

My question is that the call instruction right before the return address calls npdf!ProvideCoreHFT2+0x57cc0, while the function in frame 0 is actually npdf!ProvideCoreHFT2+0x24db0. Why such inconsistency exists? How should I proceed?

Thank you very much!

ZillGate
  • 1,173
  • 12
  • 22
  • 3
    You might have missed the `Following frames may be wrong` part ... as it is, maybe there was another function call in between those frames shown. You could look at `0x57cc0` and see whether that actually sets up a stack frame and whether that calls anything else. You could also search for call sites of `24db0`. – Jester Dec 19 '14 at 18:14
  • 2
    the offset part in any Stack Trace is not Reliabale DO NOT USE IT +24db0 +57cc0 etc will always be bogus expecially on release builds pdb is built when debugging information is correct and that is before optimization if available use resolved address (6031c980 is correct so trace that function – blabb Dec 19 '14 at 18:22
  • @Jester Thank you! I think you are right. There are function calls between the two frames shown in the call stack. When looking at +0x57cc0, I found even more function calls... – ZillGate Dec 22 '14 at 04:47
  • @blabb Thank you! I will do as you said. – ZillGate Dec 22 '14 at 04:48

0 Answers0