Holy cow, I wrote a book!
When debugging, you may find that the stack trace falls apart:
001af118 773806a0 ntdll!KiFastSystemCallRet
001af11c 7735b18c ntdll!ZwWaitForSingleObject+0xc
001af180 7735b071 ntdll!RtlpWaitOnCriticalSection+0x154
001af1a8 2f6db1a9 ntdll!RtlEnterCriticalSection+0x152
001af1b4 2fe8d533 ABC!CCriticalSection::Lock+0x12
001af1d0 2fe8d56a ABC!CMessageList::Lock+0x24
001af234 2f6e47ac ABC!CMessageWindow::UpdateMessageList+0x231
001af274 2f6f040e ABC!CMessageWindow::UpdateContents+0x84
001af28c 2f6e4474 ABC!CMessageWindow::Refresh+0x1a8
001af360 2f6e4359 ABC!CMessageWindow::OnChar+0x4c
001af384 761a1a10 ABC!CMessageWindow::WndProc+0xb31
00000000 00000000 USER32!GetMessageW+0x6e
This can't possible be the complete stack.
I mean, where's the thread procedure?
That should be at the start of the stack for any thread.
What happened is that the EBP chain got broken,
and the debugger can't walk the stack any further.
If the code was compiled with frame pointer optimization (FPO),
then the compiler will not create EBP frames, permitting it to
use EBP as a general purpose register instead.
This is great for optimization, but it causes trouble for the
debugger when it tries to take a stack trace through code
compiled with FPO for which it does not have the necessary
information to decode these types of stacks.
Traditionally, every function began with the sequence
push ebp ;; save caller's EBP
mov ebp, esp ;; set our EBP to point to this "frame"
sub esp, n ;; reserve space for local variables
and ended with
mov esp, ebp ;; discard local variables
pop ebp ;; recover caller's EBP
This pattern is so common that the x86 has dedicated instructions
The ENTER n,0 instruction does the push / mov / sub,
and the LEAVE instruction does the mov / pop.
(In C/C++, the value after the comma is always zero.)
push / mov / sub
mov / pop
if you look at what this does to the stack, you see that this
establishes a linked list of what are called EBP frames.
Suppose you have the following code fragment:
void Top(int a, int b)
int toplocal = b + 5;
void Middle(int c, int d)
void Bottom(int e)
int bottomlocal1, bottomlocal2;
When execution reaches the ... inside function Bottom
the stack looks like the following.
(I put higher addresses at the top; the stack grows downward.
I also assume that the calling convention is __stdcall
and that the code is compiled with absolutely no optimization.)
EBP = 0040F8EC
EBP = 0040F8D8
EBP = 0040F8CC
Each stack frame is identified by the EBP value
which the function uses during its execution.
The structure of each stack frame is therefore
And the stack frames are all connected to each other in the form of
a linked list threaded through the EBP values.
This linked list is known as the EBP chain.
To recover from the broken EBP chain,
start dumping the stack a little before
things go bad (in this case, I would start at 001af384-80)
and then look for something that looks like a valid stack frame.
Since the parameters and locals to a function can be pretty much anything,
all you have left to work with is the EBP and the return
In other words, you are looking for
pairs of values of the form
«pointer a little higher up the stack».
In this case, I got lucky and didn't have to go very far:
/ 001af47c 14f4fba8 DEF!SubclassBase::CallOriginalWndProc+0x1a
| 001af480 2f6e4317 ABC!CMessageWindow::WndProc
| 001af484 00970338
| 001af488 0000000f
| 001af48c 00000000
\ 001af490 00000000
001af498 14f4fcd6 DEF!SubclassBase::ForwardMessage+0x23
001af4b0 2f6e4317 ABC!CMessageWindow::WndProc
001af4c4 14f4fb8e DEF!CView::SortItems+0x96
001af4cc 2f6e4317 ABC!CMessageWindow::WndProc
At stack address 001af478, we have a pointer to
memory higher up the stack followed by a code address.
if you follow that pointer, it points to another instance of the
same pattern: A pointer higher up the stack followed by the code address.
Once you find where the EBP chain resumes, you can ask the debugger
to resume its stack trace from that point with the =n
option to the k command.
001af478 14f4fba8 ntdll!KiFastSystemCallRet
001af494 14f4fcd6 DEF!SubclassBase::CallOriginalWndProc+0x1a
001af4f0 14f4fc8b DEF!SubclassBase::ForwardMessage+0x23
001af514 14f32dd1 DEF!SubclassBase::ForwardChar+0x59
001af530 14f4fcd6 DEF!SubclassBase::OnChar+0x3c
001af58c 14f4fd76 DEF!HelpSubclass::WndProc+0x51
001af5e4 761a1a10 DEF!SubclassBase::s_WndProc+0x1b
001af610 761a1ae8 USER32!GetMessageW+0x6e
001af688 761a1c03 USER32!GetMessageW+0x146
001af6e4 761a3656 USER32!GetMessageW+0x261
001af70c 77380e6e USER32!OffsetRect+0x4d
001af784 761a2a98 ntdll!KiUserCallbackDispatcher+0x2e
001af794 698fd0aa USER32!DispatchMessageW+0xf
001af7a4 2f7bf15c ABC!CThread::DispatchMessageW+0x23
001af7e0 2f7befc9 ABC!CMessageWindow::MessageLoop+0x3a2
001af808 2ff56d20 ABC!CMessageWindow::ThreadProc+0x9f
001af898 75c2384b ABC!CMessageWindow::s_ThreadProc+0x10
001af8a4 7735a9bd kernel32!BaseThreadInitThunk+0x12
001af8e4 00000000 ntdll!LdrInitializeThunk+0x4d
When you do this, make sure to ignore the first line of the
resumed stack trace, since that is based on your current EIP,
not the return address stored in the stack frame.
Today was really just a warm-up for another debugging technique
that I haven't finished writing up yet,
so you're just going to be in suspense for another two years or so,
though if you attended
my TechEd China talk, you already know where I'm going.
In Ryan Mangipano's two-part series on kernel mode stack overflows,
the second part does a bit of EBP chain chasing.
(Feel free to read
the first part,
as well as
earlier discussion on the subject of stack overflows.)