Let's say that you are looking at a crash dump, so following the first command from this page you do:
Part of what the command prints is:
which basically says that there is an attempt to read from NULL:
1c414c7e 8b01 mov eax,dword ptr [ecx]
and ECX is 0.
The problematic part is the last one: the stack is a single line of text, inside a DLL that you know nothing about. Moving on to the next command,
confirms what we already know as the debugger loads the context when the exception was received. The stack window shows only one line of text.
Looking at the registers show the reason: EBP is 0xF0, which is not a pointer to the stack. ESP looks fine, so let's see what's there using the next command from the list:
A few pointers to code close to the address that crashed, which is good because it means the control flow before the crash is reasonable. But clearly that code is not using EBP to maintain stack frames (more on that later). So see what else is on the stack:
Note that issuing the command without an argument just continues where the last invocation left of. Furthermore, just hitting enter repeats the last command so after this point is a matter of keep hitting enter. Which is good because in this case interesting things happen after a long time:
After a while of seeing symbols from various DLLs go through the stack we start to see symbols from Chrome. The last part looks relatively good. Note that at address 0465f298 there is a pointer to Chrome code, and more importantly, 4 bytes before there is a pointer to another place in the stack, some bytes after the current position: 0465f294 0465f4bc. This is the typical pattern of a call to a function that use EBP to track stack frames. Time to use the next command from the list:
Strictly speaking the format that I just used is not correct, but the debugger does a decent job figuring out what I want just complaining about the first frame. The good part is that now we have a stack that looks reasonable. Time to go up and try to get something better.
The pattern that we just saw, a pointer a few bytes ahead followed by a symbol should repeat itself... as in the pointer should point to another pointer followed by a symbol. Se if we search up on the debugger output for 0465f294 we should get to the previous frame. If there is no match, it means that either we reached a function call that doesn't use EBP, or we are following stale data from the stack (traces of something that happened before, and has not been overwritten yet, but it is not the current call sequence).
And that's exactly what happens in this case. But going up and following stack manually a few times provides a better stack. Remember that the goal is not to get a perfect stack trace but to get enough information to do something about it. We already know that get the actual stack will be impossible because close to the crash point there's no EBP and no symbols. But the type of symbols that you see going through while executing dds gives you a rough idea of how the flow ends up at the code that crashes.
Note how this stack is slightly different right where the previous stack started, but it flows nicely into a sequence of com calls. There's usually no point in going too deep into code we don't control, so that is all we need in this case.