Stack overflow 线程栈溢出异常，程序崩溃在汇编代码 test dword ptr [eax],eax 上的问题排查

dvlinker

已于 2025-07-30 15:01:13 修改

阅读量3.1w

点赞数 119

CC 4.0 BY-SA版权

分类专栏： C++软件调试与异常排查从入门到精通系列教程 C/C++实战专栏文章标签： C++ Stack overflow 线程栈溢出 Windbg静态分析 Windbg动态调试汇编调试

于 2023-07-15 19:42:36 首次发布

本文为博主原创文章，未经博主允许不得转载。

本文链接：https://blog.youkuaiyun.com/chenlycly/article/details/131743305

C/C++实战专栏同时被 2 个专栏收录

518 篇文章 ¥89.90 ¥99.00

订阅专栏

C++软件调试与异常排查从入门到精通系列教程

223 篇文章 ¥89.90 ¥99.00

订阅专栏

本文详述了一起因线程栈溢出导致程序崩溃的问题，涉及使用Windbg静态和动态调试，以及Visual Studio进行汇编代码调试的过程。在检查dump文件和动态调试后，发现在处理特定消息时，函数中的大结构体局部变量导致栈空间超出限制。通过分析和修改代码结构，成功解决了线程栈溢出问题。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

1、问题描述

2、使用Windbg静态分析dump文件

3、将Windbg附加到进程上进行动态调试

4、使用Visual Studio进行Debug调试

4.1、使用if条件断点和汇编代码单步调试

4.2、分析消息响应函数入口处为什么会产生崩溃

VC++常用功能开发汇总（专栏文章列表，欢迎订阅，持续更新...）https://blog.youkuaiyun.com/chenlycly/article/details/124272585 C++软件异常排查从入门到精通系列教程（专栏文章列表，欢迎订阅，持续更新...）https://blog.youkuaiyun.com/chenlycly/article/details/125529931 C++软件分析工具从入门到精通案例集锦（专栏文章正在更新中...）https://blog.youkuaiyun.com/chenlycly/article/details/131405795 C/C++基础与进阶（专栏文章，持续更新中...）https://blog.youkuaiyun.com/chenlycly/category_11931267.html 上周在新版本软件的测试过程中发现，执行某个点击操作时程序就会发生闪退崩溃，问题是必现的。经排查，是崩溃在校验栈空间的运行时汇编代码文件chkstk.asm中，这个问题有较强的隐蔽性，今天就来总结一下，详细地讲述整个问题的完整排查过程。

1、问题描述

在软件中切换到会议列表页面，回去自动刷新会议列表，然后手动去点击列表中的某个会议item，会去自动请求对应会议的详细信息，然后程序就发生闪退崩溃了。这个问题是必现的，所以可能会相对好排查一些，但事实上这个问题并没有最开始想象的那么好查，这个问题具有一定的隐蔽性。

2、使用Windbg静态分析dump文件

我们在软件中安装了异常捕获模块，异常捕获模块捕获到了这次异常，并自动生成了dump文件。于是我们到对应的目录中取出dump文件使用Windbg进行静态分析。用Windbg打开dump文件后，先是看到了Access violation内存访问违例的异常：

于是使用.ecxr命令切换到发生异常的那个线程，看到发生异常的那条汇编指令，如下所示：

这条汇编指令中访问了一个较小的内存地址，所以导致了上面的Access violation内存访问违例？访问的内存地址是0x00e00000，而我们之前讲的64KB小地址内存区是指0x00000000 - 0x0000FFFF这个地址范围，显然当前的0x00e00000不在这个64KB小地址内存区域中。至于为什么会崩溃，就要继续向下分析了。

于是输入kn命令查看函数调用堆栈：

因为没有加载相关模块的pdb文件，所以函数调用堆栈中看不到具体的函数。这时需要根据函数堆栈中显示的模块，依次使用lm命令查看模块的时间戳信息，查找对应版本的时间戳。以directui.dll为例，如下所示：

然后根据时间戳（模块的编译生成时间）到文件服务器上去找pdb文件。

将函数调用堆栈中相关模块的pdb文件拿来后，将pdb文件路径设置到Windbg中，然后重新输入.ecxr命令切换到发生异常的线程上下文，然后重新输入kn命令查看包含具体函数名等详细信息的函数调用堆栈，如下所示：

从上述函数调用堆栈看，问题好像出在directui的开源框架代码中，这个就比较奇怪了，以前从来没遇到过框架代码出问题的场景。这套框架已经用了好几年了，一直都没问题的，应该不是框架的问题。关于使用Windbg静态分析分析dump文件的一般步骤与要点说明，可以参见我之前写的文章：

使用Windbg静态分析dump文件的一般步骤及要点详解https://blog.youkuaiyun.com/chenlycly/article/details/130873143 所以，静态分析dump文件也没有分析出来，陷入了僵局，这比原先想象的要复杂不少。刚开始联调就出现这样的问题，着实有些棘手，耽误联调时间。这是主要功能点，没法绕过去，必须要继续排查。

3、将Windbg附加到进程上进行动态调试

既然静态分析dump文件查不出问题，所以尝试将程序重新启动起来，然后将Windbg附加到进程上进行动态调试，看看动态调试能否得到有用的线索。问题是必现的，按照之前的复现步骤复现异常，Windbg感知到并中断下来，如下所示：

动态调试果然有效果，看到了软件发生了Stack overflow线程栈溢出的异常。

但使用kn命令看到的函数调用堆栈，和之前dump文件中显示的函数调用堆栈是一样的，如下所示：

虽然知道了发生线程栈溢出的异常，但从函数调用堆栈中还是分析不出来问题，directui框架不应该有问题，都用了好几年了，如果有缺陷，应该之前就会暴露出来了，至此这个问题还是很迷茫。

于是沿着当前的函数调用堆栈，一个函数一个函数看，但始终没看到明显会引发线程栈溢出的代码，比如定义了一个很大的局部结构体变量、函数递归调用或者函数调用上的死循环。但查看了当前线程的函数调用中的所有的函数，都没找到问题。

关于使用Windbg动态调试目标进程的一般步骤与要点说明，可以参见我之前写的文章：

使用Windbg动态调试目标进程的一般步骤及要点详解https://blog.youkuaiyun.com/chenlycly/article/details/131029795

HANDLE handle;
handle = CreateFile(strHeadPicFilePath, GENERIC_WRITE, FILE_SHARE_READ,
    NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);
if (handle == INVALID_HANDLE_VALUE)
{
    DWORD dwLastError = GetLastError();

    strLog.Format(_T("[DownloadHeadPicFunc] 创建图片文件失败：%s，GetLastError：%d."),
        strHeadPicFilePath, dwLastError);
    WriteLog(strLog);

    CloseHandle(handle);
    continue;
}

DWORD dwNumByteWritten = 0;
WriteFile(handle, chunk.memory, chunk.size, &dwNumByteWritten, NULL);
CloseHandle(handle);
free(chunk.memory);

在这里，给大家重点推荐一下我的几个热门畅销专栏，欢迎订阅：（博客主页还有其他专栏，可以去查看）

专栏1：（该精品技术专栏的订阅量已达到10000多个，专栏中包含大量项目实战分析案例，有很强的实战参考价值，广受好评！专栏文章持续更新中，已经更新到210篇以上！欢迎订阅！）

C++软件调试与异常排查从入门到精通系列文章汇总https://blog.youkuaiyun.com/chenlycly/article/details/125529931

本专栏根据多年C++软件异常排查的项目实践，系统地总结了引发C++软件异常的常见原因以及排查C++软件异常的常用思路与方法，详细讲述了C++软件的调试方法与手段，详细介绍分析C++软件问题的常用分析工具，以图文并茂的方式给出具体的项目问题实战分析实例（详细讲述分析排查过程，很有实战参考价值），带领大家逐步掌握C++软件调试与异常排查的相关技术，适合基础进阶和想做技术提升的相关C++开发人员！

考察一个开发人员的水平，一是看其编码及设计能力，二是要看其软件调试能力！所以软件调试能力（排查软件异常的能力）很重要，必须重视起来！能解决一般人解决不了的问题，既能提升个人能力及价值，也能体现对团队及公司的贡献！

专栏中的文章都是通过项目实战总结出来的，包含大量项目问题实战分析案例，有很强的实战参考价值！专栏文章还在持续更新中，预计文章篇数能更新到300篇以上！

专栏2：（本专栏涵盖了C++多方面的内容，是当前重点打造的专栏，订阅量已达8000多个，专栏文章已经更新到500多篇，持续更新中...）

C/C++实战进阶（专栏文章，持续更新中...）https://blog.youkuaiyun.com/chenlycly/category_11931267.html

以多年的开发实战为基础，总结并讲解一些的C/C++基础与项目实战进阶内容，以图文并茂的方式对相关知识点进行详细地展开与阐述！专栏涉及了C/C++领域多个方面的内容，包括C++基础及编程要点（模版泛型编程、STL容器及算法函数的使用等）、数据结构与算法、C++11及以上新特性（开源代码中可能会用到很多新特性（比如WebRTC开源库），日常编码中也会用到部分新特性，面试时也会频繁地涉及到，学习新特性很有必要）、常用C++开源库的介绍与使用（比如SQLite、libcurl、libwebsockets、libevent、jsoncpp/RapidJson、Redis、RabbitMQ、MongoDB、MQTT、ZooKeeper、OpenCV、FFmpeg、SDL、GStreamer、Live555、ReactOS等）、代码分享（调用系统API、使用开源库）、常用编程技术（动态库、多线程、多进程、数据库及网络编程等）、软件UI编程（Win32/duilib/QT/MFC）、C++软件调试技术（引发C++软件异常的常见原因分析与总结、排查C++软件异常的手段与方法、分析C++软件异常的基础知识、使用常用软件分析工具分析C++软件问题、多个项目实战问题分析案例分享等）、设计模式（单例模式、工厂模式、观察者模式、状态模式等）、网络基础知识与网络问题分析进阶内容（实战问题分析实例分享）等。本专栏的内容都是建立在项目实践的基础上，来源于项目实战，服务于项目实战，很有实战参考价值！

专栏3：

C++常用软件分析工具从入门到精通案例集锦汇总（专栏文章，持续更新中...）https://blog.youkuaiyun.com/chenlycly/article/details/131405795

常用的C++软件辅助分析工具有SPY++、PE工具、Dependency Walker、GDIView、Process Explorer、Process Monitor、API Monitor、Clumsy、Windbg、IDA Pro等，本专栏详细介绍如何使用这些工具去巧妙地分析和解决日常工作中遇到的问题，很有实战参考价值！

专栏4：

VC++常用功能开发汇总（专栏文章，持续更新中...）https://blog.youkuaiyun.com/chenlycly/article/details/124272585

将10多年C++开发实践中常用的功能，以高质量的代码展现出来。这些常用的高质量规范代码，可以直接拿到项目中使用，能有效地解决软件开发过程中遇到的问题。

专栏5：

C++ 软件开发从入门到精通（专栏文章，持续更新中...）https://blog.youkuaiyun.com/chenlycly/category_12695902.html

根据多年C++软件开发实践，详细地总结了C/C++软件开发相关技术实现细节，分享了大量的实战案例，很有实战参考价值。

4、使用Visual Studio进行Debug调试

既然Windbg静态和动态调试都没定位问题，因为问题是必现的，Debug下也是必现的，所以决定使用Visual Studio进行Debug下的调试。按照问题的复现步骤操作，程序产生异常，Visual Studio中断下来，如下所示：

代码崩溃在汇编文件chkstk.asm中的这行汇编代码上：test dword ptr [eax],eax，这点和Windbg看到的是一致的。弹出的提示框中也提示发生了Stack overflow线程栈溢出异常！

打开调用堆栈页面查看当前的函数调用堆栈：

调用堆栈和Windbg中显示一致，于是进入最后一个函数，到函数内部去详细看一下。

4.1、使用if条件断点和汇编代码单步调试

点击会议列表中的会议item时会向服务器发起请求会议详情的请求，等服务器回应后，底层会给UI层投递一个消息EVENT_UI_CONF_DETAILINFO_NTF，在消息中携带会议详细信息数据。如果将获取会议详情的代码注释掉，程序就不会崩溃，所以肯定和这个会议详情请求有关。

既然崩溃在上述函数中，于是在上述函数中打断点进行单步调试。上述函数的功能是处理窗口的自定义消息，收到消息后到映射表中找到消息对应的响应函数去执行响应函数，所以人为地在代码中添加一个条件断点，以EVENT_UI_CONF_DETAILINFO_NTF消息id进行过过滤（消息id宏EVENT_UI_CONF_DETAILINFO_NTF的值为12054），如下所示：

人为添加if条件断点，很好用，比Visual Studio中的条件断点要灵活方便很多，建议使用这种人为添加的if条件断点，我们在项目中基本都用这种方式。

问题应该就出在：

(this->*mmf.pfn_bwlb)( wParam, lParam, bHandled );

这行源码就一行，怎么进行单步调试呢？C++源码是只有一行，但程序最终执行的是汇编代码，一行C++源码可能对应多行汇编代码，可以在运行到断点处，右键点击：

在弹出的右键菜单中点击“转到反汇编”菜单项，跳转到汇编代码页面，单步去调试汇编代码。就在这时，突然想起来，好像忽略了一个问题排查点，有没有可能是EVENT_UI_CONF_DETAILINFO_NTF消息响应函数CXXXXMsgRecver::OnConfDetailInfoInd中有问题，于是又在该函数的入口处添加断点：

然后命中断点后右键查看汇编代码，然后单步调试汇编代码。经调试发现，问题果然出在响应函数CXXXXMsgRecver::OnConfDetailInfoInd的入口处：

单步调试上面的汇编代码，发现最终崩溃在_chkstk这个函数调用的地方，所以就是崩溃在当前函数的入口处，在崩溃时显示的函数调用堆栈中不显示当前的响应函数，可能和崩溃在函数入口处有关。

4.2、分析消息响应函数入口处为什么会产生崩溃

已经确定问题出在EVENT_UI_CONF_DETAILINFO_NTF消息的响应函数CXXXXMsgRecver::OnConfDetailInfoInd中了。下面就要看看这个函数入口处为啥会发生崩溃了！

于是详细查看了CXXXXMsgRecver::OnConfDetailInfoInd函数的代码，不看不知道，一看就知道，函数中根据不同的会议类型分了几个if条件分支，每个分支都使用对应的结构体定义了局部变量，代码片截图如下所示：

即分别使用了TMTInstantConferenceInfo_Api、TMTBookConferenceInfo_Api和TMTVConfDetailInfo_Api三个结构体定义了局部变量，这三个结构体都是比较大的，定义的局部变量都是在栈上分配的，问题就出在这里了。

此处，需要注意一下，虽然这三个结构体变量是定义在if条件体内部的，作用域位于这些if条件体中，即生命周期在if条件体中，但三个结构体变量占用的栈空间在函数入口处就分配好了（关于这一点可以编写几个分支代码，在Visual Studio中查看汇编代码去验证）。因为结构体很大，所以在分配好三个结构体变量栈内存后，调用_chkstk汇编实现的函数去校验线程栈内存时，发现超过了当前线程的栈的上限，所以触发了Stack overflow线程栈溢出的异常。

为啥同样的代码在之前的版本中运行不会产生线程栈溢出，现在就会出现呢？初步估计可能是TMTInstantConferenceInfo_Api、TMTBookConferenceInfo_Api和TMTVConfDetailInfo_Api这三个结构体的定义有变动了，比如新增了一些字段，于是去这三个结构体的头文件中去查看svn上的修改记录，果然发现前段时间有人修改了TMTBookConferenceInfo_Api结构体，新增了以下若干个字段：

正因为这些新增的字段导致原本不会栈溢出的，现在发生栈溢出了！

4.3、解决办法

问题定位出来了，修改办法其实很简单，只要将在栈上分配内存的局部变量改成指针或者到堆上申请内存的对象即可。修改后的代码片段为：（不再定义局部变量接收，直接定义指针接收即可）

5、线程栈溢出的相关细节点说明

哪些对象会占用线程的栈内存呢？函数中的局部变量是在线程栈上分配的，函数调用时主调函数传给被调函数的参数时通过栈内存传递的（将要传递的参数内存中的值压到栈上），他们会占用线程的栈内存。

系统在创建线程时，会给线程分配指定大小的栈内存，在默认情况下，Windows系统默认会给线程分配1MB栈内存、Linux系统默认会给线程分配2MB栈内存。某个线程在某一时刻函数调用堆栈中所有函数占用的栈内存总和，就是当前线程在此时的总的栈内存占用。如果某时刻线程占用的总的栈内存超过系统给该线程分配的栈内存上限时，就会触发Stack overflow线程栈溢出异常。

6、引发线程栈溢出的常见原因和场景总结

引发线程栈溢出问题可能有以下几个可能：

1）函数递归调用的深度过深
因为一直在递归调用，在到达最底下的那层调用之前，递归函数一直没返回，栈空间一直没有释放，导致当前线程占用的栈空间越来越多，达到上限。
2）消息上触发函数的死循环调用
消息触发的函数死循环调用，因为死循环调用了，函数的栈空间一直没释放，导致当前线程占用的栈空间越来越多。这个问题我们在实际项目中遇到过两次。
3）定义了一个占用内存很大的局部变量
比如定义了一个很庞大的结构体，在一个函数中用该结构体定义了一个局部变量，假设该结构体接近或者大于1MB，则会直接导致线程栈溢出。
4）函数中使用switch...case语句，包含了大量的case分支
每个case分支中都定义了局部变量，导致当前函数占用了大量的栈空间。case分支中的局部变量的生命周期是在case分支中的，即代码运行到对应的case分支中时该分支中的局部变量才有“生命”，但其实这个局部变量的栈空间已经在函数入口处分配好栈空间了，并不是代码执行到case子句中才分配栈空间的。这点可以通过编写测试代码，查看函数入口处给当前函数分配栈空间的汇编代码就能看出来了，可以先顶一个变量查看汇编代码看看分配了多少栈空间，然后再增加一个变量，看看分配的栈空间是否变大。

5）多个if-else分支，每个分支中都有定义局部变量

引发问题的原因与多个case语句的场景是一样的，此处就不再赘述了。本问题案例的场景，就是与if-else分支有关系的。

7、调试汇编代码

CPU中执行的是一句一句汇编代码（或者叫二进制机器码，两者是等价的），看汇编代码才能看到代码的执行细节。一行C++源码可能对应多行汇编代码，有时我们要知道C++源码为何有问题，可以尝试在Visual Studio中转到汇编代码页面，去单步调试汇编代码，通过调试汇编代码去寻找真相。本案例就是一个通过调试汇编代码去排查问题的典型实例。