栈溢出崩溃排查(二)

(接上文)

竟然全是0，试着输出再多一些，输入dps esp L100，终于能看到熟悉的调用栈了，当然这种形式与我们平时看windbg的不同，这里把调用栈的原始数据输出了，具体调用流程，还要我们自己去分析。

实际上到这里，已经猜到十有八九是发生了栈溢出，其判断理由有二，第一EIP和EBP的值同时被覆盖掉了，第二EIP和EBP的值跟ESP指向的栈上的值相同，都是0，想想函数的调用过程，当函数调用时，首先会把返回地址，原EBP压栈，当函数返回时，再将EBP，返回地址弹出栈，这时EIP，EBP就跟栈上的数据一致，这种情况下，就是原来压入堆栈的返回地址，EBP值被覆盖了。

接下来的工作，就是要找到在哪里发生了栈溢出，从图中可以看到，很多地方要么是系统的要么是第三方的，我们找到自己写的代码离系统调用最近的那部分，藉此作为突破口。

图中可以清楚看到，windbg为我们指出了一个位置，download.cpp 的第129行。由于离当前调用栈很远，这一般不是发生栈溢出的位置，我们可以从这里继续跟踪下去，直到发生问题的最终现场。

 

三、追踪问题现场，找出幕后元凶

在windbg为我们指明的代码处下断点，进行单步调试。

通过单步跟踪，发现问题发生在这一行

这是一个帧分析库的API，当调用(图中隐去API名称)时，会将结果返回到packet变量中，从下图中可以看出，当调用该API时，影响了从packet变量起始的0x2F2AF888~~0X2F2AF8F8总共116个字节，而在IDE中看到，packet实际只有80个字节，因此这里造成了栈溢出。

一般这种情况是，所使用的DLL库版本对该结构体的定义不一致造成，这就是著名的DLL HELL，统一下该帧分析库的版本，问题迎刃而解。