【Dump分析】记录一次工控软件程序卡死分析

前言

      我前阵子迷上了dump分析，于是常常找时间百度查教程，从windgb的安装，到把其他博客里面提到的分析指令记下来，再到自己上手查bug，前前后后，感触颇多。因为用windgb去分析dump文件的方式，从而达到对软件运行过程的各项参数、变量、状况的知晓，进而对代码进行优化。用这个过程去做软件性能优化的程序员真的很少，甚至很多程序员都不知道dump和windgb为何物，就算知道都没有亲自去接触过，因为普通问题加个log就能找到，谁来学这个玩意呢？扯远了，继续回到主题。

起因

       前几天公司的设备在客户现场突然出现了状况，现场的售后和客户反馈说设备跑着跑着突然不动了，软件界面也没有卡死，看样子属于软件程序加入了某一段循环卡死了没有出来，导致软件流程处于等待状态。由于设备上是没有源代码的，而且通过拷回来的日志只是确认到程序进入到了模组点亮的程序段，具体是什么问题，还无法判断出来。

排查过程

     按照以前的做法，只能让客户重启设备，自己再慢慢查日志和代码，但是由于我学dump文件分析有了一段时间，起码学会了点皮毛，于是在设备的主控软件没有任何操作的情况下，我远程过去拿到了dump，开始进行本地分析。

     按照之前看到其他博主对于此类问题的解决步骤，一般都是先看看是不是线程之间存在了互锁的情况，我也是牙牙学语，学着其他博主用!syncblk 观察同步块表

0:000> !syncblk
Index SyncBlock MonitorHeld Recursion Owning Thread Info  SyncBlock Owner
 2876 000001c782a614f8           11         1 000001c782b6a590 a38  54   000001c7b4f835a8 System.Object
 3216 000001c789306758            3         1 000001c789656350 680  91   000001c7b57d2888 System.Object

 查询后的情况如上，可以看到54号线程和91号线程都处于临界区资源获取那里，按照其他博主的说法，这里就是可能存在死锁了。于是可以单独查一下这两个线程都在干啥

54号线程堆栈如下

91号线程堆栈如下

从上面的堆栈信息可以比较清晰的看到91号线程调用程序的脉络，结合我们的代码，发现54号线程正在处于读取电流值，而91号线程正在处于模组点亮的stop环节，于是根据这个情况我问了同事，他和我说读取电流那里是属于后台线程在操作，对于其他程序没有影响。既然如此，为什么还会出现这个情况呢？对于这个我也是有些不理解。但是对于91号线程正在干的事情，电子部门的同事给出的推断是可能硬件挂了导致stop环节的程序处于某个死循环没有出来，进而导致外面调用的程序出现了异常等待状态。后来电子部门的同事远程更新了相关硬件的驱动后，问题得到解决。

结尾

      虽然这次bug的查询有些稀里糊涂，因为几乎是完全照搬其他博主的经验去找到问题的，但是还好问题解决了。如果不是通过这种方式去解决，按照以外的方式就是要不断对比日志和代码，那将是一个不断自我怀疑的过程。不过这次的bug解决更加坚定了我对于dump文件分析的学习，因为这个确实可以解决内存泄漏、内存溢出、软件闪退、软件卡死等玄学问题，加油！痛并快乐着！