山东省建设人才网站,信息网站开发合同,越秀金融大厦,2345网址大全设主页目录
1、问题说明
2、线程堵塞的可能原因分析
3、使用Windbg和Process Explorer确定线程中发生了死循环
4、根据Windbg中显示的函数调用堆栈去查看源码#xff0c;找到问题
4.1、在Windbg定位发生死循环的函数的方法
4.2、在Windbg中查看变量的值去辅助分析
4.3、是循环…目录
1、问题说明
2、线程堵塞的可能原因分析
3、使用Windbg和Process Explorer确定线程中发生了死循环
4、根据Windbg中显示的函数调用堆栈去查看源码找到问题
4.1、在Windbg定位发生死循环的函数的方法
4.2、在Windbg中查看变量的值去辅助分析
4.3、是循环计数值没有累加导致的
5、可以从动态调试的Windbg中导出dump文件
6、最后 C软件异常排查从入门到精通系列教程专栏文章列表欢迎订阅持续更新...https://blog.csdn.net/chenlycly/article/details/125529931C/C基础与进阶专栏文章持续更新中...https://blog.csdn.net/chenlycly/category_11931267.htmlVC常用功能开发汇总专栏文章列表欢迎订阅持续更新...https://blog.csdn.net/chenlycly/article/details/124272585C软件分析工具从入门到精通案例集锦专栏文章持续更新中...https://blog.csdn.net/chenlycly/article/details/131405795开源组件及数据库技术专栏文章持续更新中...https://blog.csdn.net/chenlycly/category_12458859.html网络编程与网络问题分享专栏文章持续更新中...https://blog.csdn.net/chenlycly/category_2276111.html 软件运行过程中有线程发生堵塞是时常发生的事最近就遇到一个典型的案例虽然分析过程不是很复杂但很有代表性在这里给大家分享一下这个问题的详细排查过程希望能给大家提供一个借鉴或参考。使用Process Explorer和Windbg排查软件线程堵塞问题
1、问题说明 某天客户在使用我们软件的过程中遇到了问题在其Windows10系统中运行我们的客户端软件加入了一个会议一直在开会没有做其他的操作中间某个时间点用鼠标去点击软件窗口时发现点击没反应好像是软件UI界面卡死了但会议窗口中还能看到正在动的远端视频能听到远端的声音应该是UI线程卡死了其他线程还在正常运行。这个问题比较严重无法操作软件界面了如果领导那边出现这样的问题就比较麻烦了。于是联系到我们希望我们尽快协调研发人员排查定位一下。 我们研发这边接到任务后和客户取得了联系通过远程软件远程连到他的电脑上。我们初步怀疑是软件的UI界面所在的主线程卡死或堵塞了于是将SPY、Process Explorer和Windbg等工具拷贝到客户的电脑上准备详细分析一下。 在这里给大家重点推荐一下我的几个热门畅销专栏
专栏1该专栏订阅量接近350个有很强的实战参考价值广受好评专栏文章持续更新中预计更新到200篇以上
C软件调试与异常排查从入门到精通系列文章汇总https://blog.csdn.net/chenlycly/article/details/125529931 本专栏根据近几年C软件异常排查的项目实践系统地总结了引发C软件异常的常见原因以及排查C软件异常的常用思路与方法详细讲述了C软件的调试方法与手段以图文并茂的方式给出具体的实战问题分析实例带领大家逐步掌握C软件调试与异常排查的相关技术适合基础进阶和想做技术提升的相关C开发人员 专栏中的文章均是通过项目实战总结出来的通过项目实战积累了大量的异常排查素材和案例有很强的实战参考价值专栏文章还在持续更新中预计文章篇数能更新到200篇以上 专栏2
C/C基础与进阶专栏文章持续更新中...https://blog.csdn.net/chenlycly/category_11931267.html 以多年的开发实战为基础总结并讲解一些的C/C基础与进阶内容以图文并茂的方式对相关知识点进行详细地展开与阐述专栏涉及了C/C领域的多个方面的内容同时给出C/C及网络方面的常见笔试面试题并详细讲述Visual Studio常用调试手段与技巧 专栏3
开源组件及数据库技术https://blog.csdn.net/chenlycly/category_12458859.html 以多年的开发实战为基础分享一些开源组件及数据库技术 2、线程堵塞的可能原因分析 软件为了并发处理事务一般都使用了多线程如果代码处理不当可能就会出现线程堵塞或卡死问题。一般是个别线程的堵塞其他线程还是正常执行的发生堵塞的线程中处理的业务出现异常。 对于客户端软件一旦有线程发生异常我们可以通过软件界面的异常表现感知到然后通过日志去大概地确定发生异常的业务线程。在本例中UI界面不能操作了判断应该是UI界面所在的主线程堵塞了。会议中音视频的解码播放是在底层模块的其他线程中进行的这些线程是正常运行的所以还能看到视频画面、听到会议中的声音。 导致线程发生堵塞或卡死的原因主要有两种 1死锁软件中多线程发生了死锁某个线程需要获取某个锁但因为死锁导致该锁一直没释放导致线程一直卡在WaitForSingleObject等等待函数接口上没返回所以线程卡住了2死循环当前线程中某个函数中发生了死循环接口调用一直没返回导致线程卡住了。如果是死循环还会导致一个现象死循环会占用大量的CPU时间片导致程序进程占用较高的CPU用Process Explorer工具则可以看到某个线程的CPU占用的特别高这个线程就是发生死循环的线程。 在本案例中出问题的是UI客户端软件客户端界面没法操作了可能是界面所在的UI线程UI程序的主线程发生了堵塞可能是死锁或死循环导致的。UI界面没法操作还有另外一个原因可能是窗口被disable了窗口之前在执行某个操作时被disable了比如弹出了一个模态框在执行完操作后出现异常没有将窗口恢复到enable状态这个问题场景我们以前在项目中遇到过几次。我们可以用SPY工具查看一下当前不能操作的窗口属性如果是当前的窗口被disable导致窗口不能操作的那么使用SPY查看的窗口属性中应该能看到 WS_DISABLED 窗口风格如下所示 但本例中界面不能操作不是窗口被disable导致的。 对于腾讯会议、企业微信、字节飞书、阿里钉钉等这类Windows桌面客户端软件UI界面所在的线程称为UI线程也是软件的主线程。如果UI界面或窗口不能操作了可能就是UI线程出问题发生堵塞了。 在Windbg中被分析的软件有多个线程线程除了有线程id还有个线程编号编号从0开始UI主线程的编号就是0Windbg切换线程的命令~ns中的n就是线程编号。 3、使用Windbg和Process Explorer确定线程中发生了死循环 当时软件的UI窗口不能操作了使用SPY查看窗口属性窗口并没有被disable掉所以基本可以断定UI界面所在的UI线程发生堵塞了。 那这个线程堵塞是死锁引起的还是死循环引起的呢其实要确定这个问题很简单当前程序进程还在的只需要将Windbg附加到问题进程上切换到0号UI主线程上面已经讲了UI程序的UI界面就在UI主线程中然后查看该线程的函数调用堆栈如果堆栈中调用了WaitForSingleObject或NtWaitForAlertByThreadId进入临界区时会调用该函数等等待函数时就能确定是线程发生死锁了。 这个地方需要提一下线程堵塞和程序崩溃是两个完全不同的概念和场景要注意区分一下 1对于堵塞堵塞只是发生在个别线程中其他线程还是正常的程序进程没有退出进程还在的此时可以将Windbg附加到进程上调试的。2对于程序崩溃如果没弹出崩溃提示框程序直接闪退程序进程就不存在了就没有机会将Windbg附加到进程上分析了。如果程序没有生成dump文件只能在下次运行程序时将Windbg附加到进程上动态调试Windbg和目标程序一起跑然后去复现崩溃一旦程序发生崩溃Windbg就会感知到并中断下来就可以分析了。此外如果程序崩溃时弹出了系统报错提示框只要不将该提示框点掉则进程还在的此时还有机会将Windbg附加到进程上进行分析的我们在项目中遇到过这样的场景。 将Windbg附加到当前出问题的程序进程上使用~0s命令切换到UI线程中然后输入kn命令查看UI线程此刻的函数调用堆栈如下所示 因为没有加载pdb符号文件所以堆栈中看不到具体的函数名。于是使用lm命令查看堆栈中dll模块的时间戳到我们的文件服务器上找到对应时间点的pdb文件我们已经将各个版本的安装包、二进制文件和pdb文件保存到文件服务器上维护起来了然后将pdb文件路径设置到Windbg中重新执行~0s和kn命令查看UI线程的详细函数调用堆栈信息如下所示 加载pdb文件后调用堆栈中就可以看到具体的函数名了但没有看到WaitForSingleObject或NtWaitForAlertByThreadId进入临界区时会调用该函数等等待函数的调用所以基本可以断定UI线程的堵塞和死锁没有关系。 基本只有一种可能UI线程中的某个函数发生死循环了。死循环就是一直在执行代码会占用大量的CPU时间片死循环所在的线程会占用较高的CPU比例直接导致程序进程占用较高的CPU。这个我们可以使用Process Explorer工具核验一下打开Process Explorer在进程列表中找到当前出问题的进程然后双击该进程条目查看进程的属性在弹出的属性页面中点击Threads标签页在该页面中可以查看到当前进程的各个线程信息包括线程占用的CPU比例以及线程此刻的函数调用堆栈。 Process Explorer查看线程的函数调用堆栈可能不准确可以使用另一个类似的工具Process Hacker这个工具看线程的函数调用堆栈比较准确 查看到如下的线程列表 果然看到了一个线程占用了20%的CPU但只能看到线程号我们如何确定这个线程就是当前出问题的UI主线程呢 其实很简单我们可以回到Windbg中使用~命令打印出当前问题进程的所有线程如下所示 我们上面讲了UI应用程序的UI主线程在Windbg中的线程序号就是0看着上述线程列表第一个条目就是0号线程就是UI主线程找到其对应的线程id为0x2e2016进制转换成10进制数据为11808即UI线程的线程id为11808然后跳回到Process Explorer的线程列表页面占用CPU高的线程就是UI主线程。所以可以确定UI线程中有函数发生死循环了。
4、根据Windbg中显示的函数调用堆栈去查看源码找到问题 确定UI线程发生了死循环下面只要根据Windbg中显示的UI线程的函数调用堆栈去查看C源码去分析为什么出现死循环就可以了。 回到Windbg中使用~0s命令切换到UI线程中然后输入kn命令查看UI线程的函数调用堆栈如下所示 之前已经设置pdb到windbg中了所以堆栈中显示了详细的函数名和代码行号看到最后调用的一个函数是xxxlib!LoginManager::OnSrvAddrsChangedNtf。
4.1、在Windbg定位发生死循环的函数的方法 这个地方说几个关于使用Windbg排查死循环的技巧。 我们当前的问题相对较简单没用到此处提的方法。大家后面可能会用到所以在此说明一下。 如果当前要确定当前线程是否发生死循环可以尝试多次输入g命令让程序继续跑然后再break中断下来如果每次堆栈都是一样的话可能发生死循环了。但这个需要我们根据调用堆栈辨别一下不是堆栈一样就一定是死循环比如我们的某个业务线程就在循环执行业务每次查看的堆栈肯定是一样的这不是程序中发生了死循环。业务线程中虽然是个循环但中间会人为sleep一下不让线程跑满。 此外我们在Windbg中可以使用bp命令设置断点比如可以在函数调用堆栈中的多个函数中设置断点然后输入g命令让程序继续跑看都命中了哪些函数中的断点这样就能确定死循环发生在哪个函数中了。 Windbg中支持设置断点相关的命令如下 1bp添加断点 2bc清除断点 3bl列出断点 4ba设置数据断点。 这几个命令的详细说明及使用方法可以查看Windbg帮助文档文档中有相关的示例可以参考。 4.2、在Windbg中查看变量的值去辅助分析 以前我们多次讲过可以尝试在Windbg中查看函数中局部变量或者函数所在类的成员变量的值某些变量的值可能是分析问题的关键线索。在Windbg中查看变量的值有几个场景此处说明一下 1当前用Windbg分析的是小dump文件程序中安装的异常捕获模块捕获到的文件比较小可能就几MB大小dump文件中只保存了少部分变量的值能不能看到自己想看的变量的值要看运气的。 2当前用Windbg分析的是全dump文件从Windows任务管理器中导出的或者从正在动态调试的Windbg中使用.dump命令导出的全dump保存了所有内存信息其大小接近当前进程占用的用户态虚拟内存的大小可以看到所有变量的值。 如果要查看程序中全局变量的值可以使用x命令去搜索前提是要有pdb符号文件因为pdb文件中有变量的符号信息。 当前函数调用堆栈显示的最后一个函数是LoginManager::OnSrvAddrsChangedNtf代码如下 估计是函数中的for循环发生了死循环for循环的条件中访问了TServerAddrs_Api结构体变量的dwCount成员的值是不是这个dwCount值有问题是一个异常大的值导致循环一直跳不出来于是想查看该指针变量的值于是点击函数调用堆栈前面的序号 将所在函数的栈展开 只能看到函数所在类对象指针this值但我们想看TServerAddrs_Api* ptServerAddrs指针变量展开的结构体对象中的值。并没有显示但该结构体指针对象的值就是wParam值wParam值是能看到的所以我们是有办法看到TServerAddrs_Api* ptServerAddrs指针变量展开的结构体对象中的值的。 我们把wParam局部变量中的值0x336200a0当成指针变量TServerAddrs_Api* ptServerAddrs的值去解析需要使用Windbg的一个较复杂的命令但我们并没有记这个命令该怎么办呢我们点击this指针的超链接 这个超链接自动生成查看这个指针中变量的值的Windbg命令并执行该命令我们直接借鉴这个自动生成的命令 dx -r1 ((xxxlib!LoginManager *)0x55a8cc0) 将之改成 dx -r1 ((xxxlib!TServerAddrs_Api *)0x336200a0) 然后执行该命令 可以看到dwCount值为1所以底层传上来的数据不是异常值不是上面假定的问题。
4.3、是循环计数值没有累加导致的 我们继续查看函数pcmt_mtclib!LoginManager::OnSrvAddrsChangedNtf 这个接口是处理底层模块投递上来的消息的消息的处理函数乍一看函数没有明显问题难道是底层一直在抛这个消息导致我们的代码一直在执行导致CPU占用高 我甚至找来了维护底层模块的同事让他们看日志看看是不是底层一直在持续抛同一个消息。同事并没有找到问题后来我无意中瞄了一下代码居然是for循环中索引值没有累加导致的如下所示 没有对索引值进行自加操作导致了死循环。这么简单的问题居然如此动干戈属实不应该啊
5、可以从动态调试的Windbg中导出dump文件 当前我们到客户的电脑上将Windbg附加到目标进程上调试时如果一时半会没查出问题我们不能一直占用别人的电脑他们还有自己的事情我们可以使用.dump命令将进程的上下文信息导出到dump文件中 .dump /ma D:\1214.dmp 然后将dump文件发回去我们事后再去详细分析。
6、最后 这个案例给我们展示了如何使用工具高效地排查软件运行过程中遇到的问题虽然不复杂但讲到了使用Windbg等工具的多个细节有很大的参考价值我们在研学技能时要多关注细节多关注分析问题的思路和办法。
