2

There is something I am not understanding. Why do debuggers sometimes show only part of the call stack? The ones I tried are WinDbg and OllyDbg.

Let me explain what I mean. Consider this example:

I launched an application, and when a dialog box showed up, I attached OllyDbg to the application and paused to look at the call stack. However, I see this:

Call stack

As you can see, this is the call stack of the main thread of the application. Unfortunately, the presented call stack seems to stop at ntdll and does not continue to show the functions in the executable. Because this is the main thread, main() has definitely not returned as otherwise the process would have terminated.

When I try using WinDbg, a similar thing happens for me as shown here.

Why does this happen, and how do I find the full call stack?

1
  • if you follow the stack for the last ntdll call and ifits retrurn address is 0 then that means ollydbg has deciphered the full call stack and the ntdll call is rtluserthreadstart btw your call stack doent show a msgbox it seems to be an editbox if you are doing this in olly v2 you can fetch symbol from ms symbol server for ntdll mfc doesnt have a main in generic terms it is afxxxxxx wrapper so you probsbly cant see a main in call stack
    – blabb
    Oct 16, 2017 at 12:35

1 Answer 1

3

Olly and WinDbg generate the 'call stack' by parsing the actual stack utilizing function signatures and calling convention. When the disassembler doesn't have the signature (e.g. when the developer didn't disclose the function signatures) it can only take educated guesses based on push- and pop-instructions (thin ice).

The problem is, you actually need this information to calculate the size of the stack frames properly. Without this information, you can not tell if there is data on the stack or if its the return address of the next function.

You can overcome these issues by keeping track of calls yourself without relying on the actual stack, maintaining a call stack yourself. In cases like this, implementation often limits the depth of the tracking list.

Sadly, I can not tell you how its exactly implemented in OllyDbg. If you consider utilizing a more modern debugger, you may reach active developers capable of helping you with this.

For example, this is the current state of the call stack in x64dbg:

When Show suspected call stack frame option in the context menu in call stack view is active, it will search through the entire stack for possible return addresses. When it is inactive, it will use standard stack walking algorithm to get the call stack. It will typically get more results when Show suspected call stack frame option is active, but some of which may not be actual call stack frames.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.