Why do debuggers sometimes not show entire call stack?

Question

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:

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?

Answer 1

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.