{"id":101034,"date":"2019-02-06T23:00:00","date_gmt":"2019-02-07T14:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=101034"},"modified":"2019-03-18T11:17:43","modified_gmt":"2019-03-18T18:17:43","slug":"20190207-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20190206-00\/?p=101034","title":{"rendered":"The Intel 80386, part 14: Rescuing a stack trace after the debugger gave up when it reached an FPO function"},"content":{"rendered":"

So here you go, minding your own business, taking a stack trace, and then the world stops. <\/p>\n

\nChildEBP RetAddr\n0019ec98 5654ef4e combase!CoInitializeEx+0x35\n0019ecf8 5654e70b WINSPOOL!GetCurrentNetworkId+0x36\n0019ed28 5654e58a WINSPOOL!InternalGetDefaultPrinter+0x8b\n0019ed58 75953b77 WINSPOOL!GetDefaultPrinterW+0x5a\n0019ed70 7594e6b8 comdlg32!PrintGetDefaultPrinterName+0x17\n0019f1b8 7594e520 comdlg32!PrintBuildDevNames+0x60\n0019f1d0 75951340 comdlg32!PrintReturnDefault+0x30\n0019f628 759a03ab comdlg32!PrintDlgX+0x132\n0019fae0 01804a8e comdlg32!PrintDlgA+0x5b\n0019fd50 7686196c contoso+0x4a8e\n<\/pre>\n
The stack trace just gives up. The function in the Cnotoso DLL was compiled with frame pointer omission (FPO), which means that the ebp<\/var> register is being used as a general-purpose register and does not point to the next frame deeper in the stack. And since we don’t have symbols for Contoso, the debugger cannot consult the symbol table to get help with unwinding the stack one more level. <\/p>\n
We’ll have to build the stack trace manually. This is basically the same exercise on every architecture: You look at the code you’re returning to, find its function prologue or epilogue, and use that information to unwind another frame. <\/p>\n
The last known good stack frame was 0019fae0<\/code> from Print­DlgA<\/code>. Let’s see what we have there: <\/p>\n
\n0:000> dps 0019fae0\n0019fae0  0019fd50                ← saved ebp\n0019fae4  01804a8e contoso+0x4a8e ← return address\n0019fae8  018083b0 contoso+0x83b0 ← argument to PrintDlgA\n0019faec  0000000e\n0019faf0  01803b8c contoso+0x3b8c\n0019faf4  0019fd50\n0019faf8  0000000e\n0019fafc  0000000e\n0019fb00  00200cce\n0019fb04  00000112\n0019fb08  0000f095\n0019fb0c  0078006b\n<\/pre>\n
The Print­DlgA<\/code> function takes a single parameter, and it uses the __stdcall<\/code> calling convention, so we know that when Print­DlgA<\/code> returns, the stack pointer will be at 0019faec<\/code>, and we will have returned to the code at 01804a8e<\/code>. We also see that the ebp<\/var> register will have the value 0019fd50<\/code>. <\/p>\n
To unwind a level, we need to disassemble at 01804a8e<\/code> and look for the code that cleans up the stack and returns to the previous function. <\/p>\n
\ncontoso+0x4a8e:\n01804a8e 833dbc83800100  cmp     dword ptr [contoso+0x83bc (018083bc)],0\n01804a95 7509            jne     contoso+0x4aa0 (01804aa0)\n01804a97 b8ffffffff      mov     eax,0FFFFFFFFh\n01804a9c 5e              pop     esi\n01804a9d c3              ret\n<\/pre>\n
For the purpose of this exercise, we are just looking for any code path that leads to a ret<\/code> instruction. We can assume conditional jumps are taken, or not taken, based on whichever case will get us to a ret<\/code> instruction faster. Along the way to the ret<\/code>, we watch for instructions that affect the esp<\/var> register, because we’ll have to simulate them in our head. <\/p>\n
In this case, we can pretend that the conditional jump is not taken, and that leads us quickly to a pop esi<\/code> and a ret<\/code>. <\/p>\n
So let’s simulate those two operations. Since our simulated esp<\/var> register is at 0019faec<\/code>, the pop esi<\/code> pops the value 0000000e<\/code> into esi<\/var>, and the ret<\/code> returns to 01803b8c<\/code>. Since this was a simple ret<\/code> with no parameters, there is no extra cleanup, and the stack pointer is left pointing to 0019faf4<\/code>. <\/p>\n
\n0019faec  0000000e                ← saved esi\n0019faf0  01803b8c contoso+0x3b8c ← return address\n0019faf4  0019fd50                ← esp points here after ret\n0019faf8  0000000e\n<\/pre>\n
Disassemble at the return address to see how to pop out another level. <\/p>\n
\ncontoso+0x3b8c:\n01803b8c 8bd8            mov     ebx,eax\n01803b8e 0bdb            or      ebx,ebx\n01803b90 7510            jne     contoso+0x3ba2 (01803ba2)\n01803b92 b8fbffffff      mov     eax,0FFFFFFFBh\n01803b97 5d              pop     ebp        ← saved ebp\n01803b98 5f              pop     edi        ← saved edi\n01803b99 5e              pop     esi        ← saved esi\n01803b9a 5b              pop     ebx        ← saved ebx\n01803b9b 81c4e8000000    add     esp,0E8h  ← adjust esp\n01803ba1 c3              ret               ← return, no extra cleanup\n<\/pre>\n
Again, we pretend that the conditional jump is not taken, and that leads us quickly to the function epilogue. We pop four values off the stack, then add 0e8h<\/code> to the esp<\/var> register before executing the ret<\/code>. Let’s simulate those operations on our stack. <\/p>\n
\n0019faf4  0019fd50       ← saved ebp\n0019faf8  0000000e       ← saved edi\n0019fafc  0000000e       ← saved esi\n0019fb00  00200cce       ← saved ebx\n0019fb04  00000112       ← esp points here after pop ebx\n<\/pre>\n
After popping ebx<\/var>, the code adds 0E8h<\/code> to esp<\/var>, so let’s ask the debugger to skip ahead 0xe8<\/code> bytes. <\/p>\n
\n0:000> dps 0019fb04+e8\n0019fbec  01801325 contoso+0x1325 ← return address\n0019fbf0  0000000e                ← esp points here after ret\n<\/pre>\n
Just keep swimming<\/a>. <\/p>\n
\n01801325 0bc0            or      eax,eax\n01801327 0f8d74040000    jge     contoso+0x17a1 (018017a1)\n0180132d 83f8fd          cmp     eax,0FFFFFFFDh\n01801330 0f846b040000    je      contoso+0x17a1 (018017a1)\n01801336 83f8fb          cmp     eax,0FFFFFFFBh\n01801339 740d            je      contoso+0x1348 (01801348)\n0180133b 83f8fc          cmp     eax,0FFFFFFFCh\n0180133e 7410            je      contoso+0x1350 (01801350)\n<\/pre>\n
Okay, we’re not so lucky this time. We don’t see the end of the function right away. The code does a bunch of stuff with the value returned by this function, but if the return value is nonnegative, it jumps ahead to 018017a1<\/code>. I’m guessing that that jump forward will take us closer to the end of the function, so let’s continue disassembling there. <\/p>\n
\n018017a1 b801000000      mov     eax,1\n018017a6 5f              pop     edi\n018017a7 5e              pop     esi\n018017a8 81c404010000    add     esp,104h\n018017ae c20c00          ret     0Ch\n<\/pre>\n
My hunch paid off. We pop two registers, adjust esp<\/var>, and then return with 12 bytes of extra cleanup. <\/p>\n
\n0019fbf0  0000000e            ← pop edi\n0019fbf4  00000111            ← pop esi\n0019fbf8  00000000            ← esp points here after pop esi\n0:000> dps 0019fbf8+0x104  ← simulate \"add esp, 104h\"\n0019fcfc  01801fea contoso+0x1fea ← return address\n0019fd00  00200cce            ← first four bytes of stack arguments\n0019fd04  0000000e            ← next four bytes of stack arguments\n0019fd08  00000000            ← last four bytes of stack arguments\n0019fd0c  00000111            ← esp points here after ret 0Ch\n<\/pre>\n
Okay, that was a little trickier because the ret 0Ch<\/code> means that after popping the return address, we also have to add 0Ch<\/code> to the esp<\/var> register, leaving it at 0019fd0c<\/code>. <\/p>\n
On to the next function. <\/p>\n
\ncontoso+0x1fea:\n01801fea 0bc0            or      eax,eax\n01801fec 0f85d6010000    jne     contoso+0x21c8 (018021c8)\n01801ff2 8b44242c        mov     eax,dword ptr [esp+2Ch]\n01801ff6 50              push    eax\n01801ff7 57              push    edi\n01801ff8 56              push    esi\n01801ff9 53              push    ebx\n01801ffa e831060000      call    contoso+0x2630 (01802630)\n01801fff 5f              pop     edi\n01802000 5e              pop     esi\n01802001 5b              pop     ebx\n01802002 83c410          add     esp,10h\n01802005 c21000          ret     10h\n<\/pre>\n
This one is a little trickier, for even though the ret<\/code> is in sight, there’s another function call in between. <\/p>\n
I’m going to assume that the function at 01802630<\/code> ends with a ret 10h<\/code>, matching the 16 bytes of parameters pushed immediately prior to the call<\/code>. This is generally a safe bet with the Microsoft C compiler, which prefers to create its entire stack frame at function entry and leave it alone until the function epilogue. <\/p>\n
That means that the epilogue starts with the pop edi<\/code>, and we can simulate those instructions as well. <\/p>\n
\n0019fd0c  00000111                ← saved edi\n0019fd10  00000000                ← saved esi\n0019fd14  01801b90 contoso+0x1b90 ← saved ebx\n0019fd18  00000070                                      \\\n0019fd1c  ffffffff                                       \\ skipped by\n0019fd20  ffffffff                                       \/ add esp, 10h\n0019fd24  768617bb USER32!UserCallWinProcCheckWow+0x1fb \/\n0019fd28  7688311b USER32!_InternalCallWinProc+0x2b ← return address\n0019fd2c  00200cce\n0019fd30  00000111\n0019fd34  0000000e\n0019fd38  00000000\n0019fd3c  00000000                ← esp points here after return\n<\/pre>\n
Hooray, we finally returned to a function we have symbols for! That means we can use the k=<\/code> command to resume our stack trace. <\/p>\n
The parameters to the k=<\/code> command are <\/p>\n