目录
1、问题说明
2、初步分析
3、使用Windbg启动程序进行动态调试
4、进一步分析
5、何时使用Windbg静态分析?何时使用Windbg进行动态调试?
6、最后
VC++常用功能开发汇总(专栏文章列表,欢迎订阅,持续更新...)https://blog.csdn.net/chenlycly/article/details/124272585C++软件异常排查从入门到精通系列教程(专栏文章列表,欢迎订阅,持续更新...)https://blog.csdn.net/chenlycly/article/details/125529931C++软件分析工具从入门到精通案例集锦(专栏文章正在更新中...)https://blog.csdn.net/chenlycly/article/details/131405795C/C++基础与进阶(专栏文章,持续更新中...)https://blog.csdn.net/chenlycly/category_11931267.html 早上测试同事反映,安装新编译出来的版本后程序始终启动不起来,之前的版本都是正常的,就今天新出的版本有问题。于是用Windbg启动程序,快速分析了一下,很快定位了问题。下面来分享一下这个问题的完整排查过程。
1、问题说明
测试同事安装完早上编译出来的软件版本,启动软件后一直没有反应,软件界面始终没有跳出来(应该显示软件的登录界面),到系统的任务管理器中查看进程一直在的,但就是没弹出软件界面。程序启动时没有报错,估计是软件底层模块出问题了。
目前软件的处理逻辑是,程序启动时会去初始化底层的模块,底层初始化完成后给上层回调一个初始化完成消息,上层在收到这个消息时会弹出软件登录界面。
2、初步分析
以前我们遇到过这类问题,原因是底层在初始化时遇到问题导致长时间初始化没有完成,上层一直没收到初始化完成的通知消息,所以一直没显示软件界面。不知道这次是不是类似的问题?还有一种可能是,程序启动时调用的底层模块初始化接口一直没有返回,可能底层发生了死锁,导致接口卡住,一直没有返回,直接导致软件UI主线程卡死,也不会弹出软件主界面。
这些都是猜测,需要详细分析后才能查出具体的原因。分析该问题的方式一般有两种,一种是查看运行日志,看看流程卡在那一块了;另一种是直接上Windbg调试器,用Windbg直接启动程序,分析启动时的运行轨迹。
3、使用Windbg启动程序进行动态调试
启动Windbg,在工具栏中点击File -> Attach to a Process...,在弹出的窗口中找到目标exe程序的路径:
选中exe程序,然后点击确定,这样Windbg就将程序启动起来了。
程序启动起来后,Windbg会附加上去,附加成功后Windbg会中断下来,如下所示:
输入g命令,将当前的中断给跳过去。但跳过去以后,显示几行信息后就不再跳动了:
似乎看不到啥有用的信息。
软件界面线程是软件主线程,对应的线程号为0,于是使用~0s切换到UI主线程:
看到了ntdll!ZwWaitForSingleObject,这个是在等待某个内核对象,估计是UI线程一直在等待对象,估计是底层发生死锁了。
4、进一步分析
于是输入kn命令查看UI主线程的函数调用堆栈,如下:
从调用堆栈中可以看出调用了WaitForSingleObject接口,因为没有加载pdb文件,所以调用堆栈中看不到有效的函数名。
函数调用堆栈中即使能看到函数名,一般都是导出接口的函数名,不是真实的函数名,相对于函数的偏移也比较大。比如getapistate+0x7b287这样的偏移,偏移值0x7b287很大,一般情况下函数不会太长,不会出现这么大的偏移值,所以一般出现较大的偏移值时显示的不是真实的函数名。
对于dll动态库,导出接口的符号对外才是可见的,很多时候是相对于导出函数的偏移,偏移可能会比较大。也有可能现对于模块名的偏移,比如libcurl++0x52396。如果要看具体的函数名,则需要拿到对应模块的pdb文件,Windbg加载pdb文件后就能显示具体的函数名了。
从函数调用堆栈中可以看到,有哪些模块,然后使用lm命令查看二进制模块的时间戳,然后再到文件服务器上找对应时间点的pdb文件。拿到这些模块的pdb文件后,放到一个文件夹中,然后将该文件夹的路径设置到Windbg中,然后重新输入kn命令查看函数调用堆栈,就能看到具体的函数名了:
这样就能确定当前问题的具体原因了。从详细的函数调用堆栈信息可以看出,程序启动时调用底层初始化的接口,然后底层模块调用WaitForSingleObject接口去获取锁,一直拿不到锁,所以函数一直没返回,导致上层的UI线程卡住了,所以软件界面一直没显示出来。于是将问题反馈给底层模块的开发维护人员,让他们去排查发生死锁的原因。
维护底层模块同事最近对底层某个模块的代码进行了重构,在处理某个线程的代码时处理的有问题,所以导致了多线程死锁!
5、何时使用Windbg静态分析?何时使用Windbg进行动态调试?
使用Windbg分析C++软件异常问题时,可以进行静态分析,也可以进行动态调试。 一般情况下,有dump文件生成时,则使用Windbg静态分析dump文件;没有dump文件时,则要尝试使用Windbg去动态调试目标进程。有时dump文件中的信息不足以分析出问题时,也可以尝试使用Windbg去动态调试。
对于包含异常上下文信息的dump文件,一般是程序中安装的异常捕获模块感知到异常崩溃自动生成的,但并不是所有的异常异常捕获模块能感知到,感知不到也就无法生成dump文件了。程序发生异常崩溃时,如果程序中安装的异常捕获模块没有捕获到,则可以尝试到系统日志中去查看系统有没有生成dump文件。如果系统没有生成,可以尝试将Windbg挂到目标进程上进行动态调试,待复现异常崩溃时,Windbg就会中断下来,就可以进行分析了。
对于系统生成dump文件的案例,可以参见我之前的案例文章:
使用Windbg分析从系统应用程序日志中找到的系统自动生成的dump文件去排查问题https://blog.csdn.net/chenlycly/article/details/132024253 关于使用Windbg静态分析dump文件的一般步骤,可以参见我之前的文章:
使用Windbg静态分析dump文件的一般步骤及要点详解https://blog.csdn.net/chenlycly/article/details/130873143 关于使用Windbg动态调试目标进程的一般步骤,可以参见我之前的文章:
使用Windbg动态调试目标进程的一般步骤及要点详解https://blog.csdn.net/chenlycly/article/details/131029795 有些软件运行异常并没有产生崩溃,比如死循环、死锁(本文中的问题就是死锁引发的)等,是没有dump文件的,需要使用Windbg进行动态调试分析。
关于何时使用Windbg静态分析、何时使用Windbg进行动态调试,可以参见我之前写的文章:
何时使用Windbg静态分析?何时使用Windbg动态调试?https://blog.csdn.net/chenlycly/article/details/131806819
6、最后
本文通过Windbg启动目标程序进行动态调试,快速定位了问题,这也充分体现了在某些场景下使用Windbg动态调试的优势。希望本文分享的内容,能给大家提供一个借鉴或参考。