Search code examples
debuggingwindbgstack-pointer

'dds esp' on Windbg


I am not sure if I am understanding the raw output of dds esp or its 64-bit counterpart dqs rsp properly. When I see a list of entries in the stack, I tend to assume that wherever I see return addresses, those are calls made by code that have not returned yet. IOW, stringing them together should form a nice call stack. (let's not bother with k* group of Windbg commands for now.) Is that not the case always?

Because there are some third party extensions, that operate on the esp/rsp output and strings together the entries into something that appear to look like a call stack but I can't seem to match that order with what I see in the source (well, whatever source I have.) There are even entries of functions that have returned long ago.

What am I missing?

UPDATE:

OK -- the third party extension I use does say:

Dumps (dps) from the stack limit the base only showing items that include the ! followed by +0x

So, the question then becomes what is that entry? I thought it was the return address of some function that is fixing to make a call into another function?


Solution

  • dds means dump dwords (32 bit) and interpret the result as a symbol. Similar for dqs (quad word, 64 bit) and dps (pointer-size, matching the architecture).

    If you read that again, you'll find the term symbol as the abbreviation, not stack. Any number which happens to be in memory will be interpreted as a symbol, if possible. That may be a method call on the stack. And it may also be a local variable which accidentally has a value matching a symbol.

    Those local variables are probably not counter variables like i and j but maybe float or double data type, which are hard to predict how they look like in memory. Also, structs might have a layout that results in an in-memory representation that looks like a symbol.

    The extension you mention seems to do a simple dps and filter lines which do not have a symbol associated.

    Still, dps is helpful in cases of stack corruption, although you need to have a good understanding of what your application does, i.e. which symbols can be on the call stack and which symbols cannot be there.