The stack excerpt below is from an x86 0xF4 crash dump. The cause of the bug check and such is irrelevant, and this stack is purely for explanatory purposes. With that said, turn off your tingly BSOD senses for a moment and look at the functions and such for what they are, and not what they could have done to play a role in the crash : )
kd> k
ChildEBP RetAddr
a1e72ccc 81a8eec4 nt!KeBugCheckEx+0x1e
a1e72cf0 81a1e85f nt!PspCatchCriticalBreak+0x73
a1e72d20 81a1e806 nt!PspTerminateAllThreads+0x2c
a1e72d54 8185c986 nt!NtTerminateProcess+0x1c1
a1e72d54 77725d14 nt!KiSystemServicePostCall
0028f0d0 00000000 0x77725d14
k* will perform a stack unwind, or more specifically will display the stack backtrace. * denotes the placeholder for the various possible parameters that we can use, such as - kb, kv, kc, kd, the list goes on. Each of those all does something different, but for now we'll stick to plain old k for example purposes.
Let's break this down one at a time!
ChildEBP
ChildEBP - First we have our ChildEBP, otherwise known as the 'base pointer', which is essentially nothing more than a pointer to a stack frame that has been set up by a piece of code (a reference to a stack of memory). As an example, let's take a look at the following command:
dd a1e72cf0 l1
dd - This is a variation of plain old d, which simply means dump. If we however use dd, this will display/dump dword(s).
a1e72cf0 - This is a pointer address from our stack, specifically from nt!PspCatchCriticalBreak+0x73.
L1 -
EDIT: Hilariously enough, someone smarter than me did happen to come along. Thanks to Blair Foster, I now understand what L1 really does.
its a size/range specifier. In the case of d* its used as size. So, dd L1 displays 1 dword, db L1 is 1 byte, etc.Thanks, Blair!
If we go ahead and run this command, here's what we get:
kd> dd a1e72cf0 l1
a1e72cf0 a1e72d20
Look familiar? a1e72d20 is another pointer address from our stack, but more specifically the pointer from the previous function in the stack - nt!PspTerminateAllThreads+0x2c. With this known, we can conclude that the ChildEBP also stores the previous function address.
a1e72d20 81a1e806 nt!PspTerminateAllThreads+0x2c
In this specific example, we don't have a good stack to show us what would happen if we went all the way back to what function spawned/began the stack. Taking a quick look through some x64 dumps (didn't have any good x86 ones), I dug up a quick stack. Try not to get overwhelmed with the differences between x86 and x64 as far as stack goes (even though there aren't really any). It's just more bits and bobs!
3: kd> k
Child-SP RetAddr
fffff880`033dfa58 fffff800`0302da3b nt!KeBugCheckEx
fffff880`033dfa60 fffff800`031f0463 hal!HalBugCheckSystem+0x1e3
fffff880`033dfaa0 fffff800`0302d700 nt!WheaReportHwError+0x263
fffff880`033dfb00 fffff800`0302d052 hal!HalpMcaReportError+0x4c
fffff880`033dfc50 fffff800`0302cf0d hal!HalpMceHandler+0x9e
fffff880`033dfc90 fffff800`03020e88 hal!HalpMceHandlerWithRendezvous+0x55
fffff880`033dfcc0 fffff800`030d84ac hal!HalHandleMcheck+0x40
fffff880`033dfcf0 fffff800`030d8313 nt!KxMcheckAbort+0x6c
fffff880`033dfe30 fffff800`030d07b8 nt!KiMcheckAbort+0x153
fffff880`09e9f638 00000000`00000000 nt!memcpy+0x208
Just by looking at the stack we can see it begins right at nt!memcpy+0x208, but let's show it the way we've been demonstrating:
3: kd> dd fffff880`033dfe30 l1
fffff880`033dfe30 00000000
We can see at address fffff880`033dfe30, the return value was zero. This tells us it wasn't called from another prior function, etc, and is the very beginning of the stack. Given the function itself is nt!memcpy, this is understandable.
RetAddr
RetAddr - Now that we understand our base pointer, we have our RetAddr, which implies return address. This is done because quite simply the CPU without being told what to do is pretty useless. We need to let it know what address to return to after it's done successfully executing the code, because all it's concerned about is instructions and executing their code. It has no idea how to handle them without this stuff set in place, or what to do after it's done. With that said, this is why we have our return address.
If we take another look at our x64 stack excerpt:
3: kd> k
Child-SP RetAddr
fffff880`033dfa58 fffff800`0302da3b nt!KeBugCheckEx
fffff880`033dfa60 fffff800`031f0463 hal!HalBugCheckSystem+0x1e3
fffff880`033dfaa0 fffff800`0302d700 nt!WheaReportHwError+0x263
fffff880`033dfb00 fffff800`0302d052 hal!HalpMcaReportError+0x4c
fffff880`033dfc50 fffff800`0302cf0d hal!HalpMceHandler+0x9e
fffff880`033dfc90 fffff800`03020e88 hal!HalpMceHandlerWithRendezvous+0x55
fffff880`033dfcc0 fffff800`030d84ac hal!HalHandleMcheck+0x40
fffff880`033dfcf0 fffff800`030d8313 nt!KxMcheckAbort+0x6c
fffff880`033dfe30 fffff800`030d07b8 nt!KiMcheckAbort+0x153
fffff880`09e9f638 00000000`00000000 nt!memcpy+0x208
According to the stack, HalpMceHandlerWithRendezvous was called by HalHandleMcheck. We know that when the work HalpMceHandlerWithRendezvous was doing was finished, it would return back to HalHandleMcheck. We can confirm this by taking a look at the return memory addresses and using the ln command:
3: kd> ln fffff800`03020e88
(fffff800`03020e48) hal!HalHandleMcheck+0x40
ln - This command will display the function/routine at or near the given address.
Bingo! Execution will resume afterwards in HalHandleMcheck, specifically 64 bytes from the start of the function.
Functions/Call Site
Functions/Call Site - Last but not least, we have our third column (it's not labeled above in any of the stack excerpts). Interestingly enough, x64 stacks do label their function columns, specifically as Call Site. In the above stack x64 excerpts however, I removed them to avoid confusion! : )
Here is what a non-edited x64 stack looks like:
3: kd> k
Child-SP RetAddr Call Site
fffff880`033dfa58 fffff800`0302da3b nt!KeBugCheckEx
fffff880`033dfa60 fffff800`031f0463 hal!HalBugCheckSystem+0x1e3
fffff880`033dfaa0 fffff800`0302d700 nt!WheaReportHwError+0x263
fffff880`033dfb00 fffff800`0302d052 hal!HalpMcaReportError+0x4c
fffff880`033dfc50 fffff800`0302cf0d hal!HalpMceHandler+0x9e
fffff880`033dfc90 fffff800`03020e88 hal!HalpMceHandlerWithRendezvous+0x55
fffff880`033dfcc0 fffff800`030d84ac hal!HalHandleMcheck+0x40
fffff880`033dfcf0 fffff800`030d8313 nt!KxMcheckAbort+0x6c
fffff880`033dfe30 fffff800`030d07b8 nt!KiMcheckAbort+0x153
fffff880`09e9f638 00000000`00000000 nt!memcpy+0x208
As we can see, there's Call Site! In x86 crash dumps however, it's not labeled. I don't need to paste the stack excerpt we used from above as I didn't edit it, so you can just scroll back up and take a quick look.
It should be no mystery that this third and final column displays the function (and routine) names throughout the stack. Do note that they are in direct correlation with the current loaded symbols. If you don't have proper symbols, you're going to get an unresolved function (or routine), and it's going to look like junk.
--------------------
Thanks for reading! In my next post I plan on going into the x86 registers (maybe x64 although it'll be a lot of work -- may save that for a future post).
No comments:
Post a Comment