dotnet 使用 windbg 运行脚本方式自动批量调试处理 dump 文件

本文将和大家介绍一个简单且实际用途不大的使用 windbg 配合脚本的方式，进行自动化的大批量对 dotnet 系应用的 dump 进行自动化分析调试处理，可以自动根据调试需求输出 dump 文件的一些信息

利用 windbg 执行调试脚本的能力，可以实现自动化调试 dump 文件，将调试 dump 文件获取的信息进行输出，方便进行统一处理

在开始之前先说一下我的需求点是什么。我有大量的用户，我也有大量的不同的软件，这些软件对接进了 dump 平台。所谓 dump 平台实际上就是软件崩了的时候，创建一个 dump 文件，然后不差钱的将 dump 文件传送到我的服务器上。我每天都会堆积几千个 dump 文件，压根调试不过来。我期望能够有一个工具可以辅助我提前预处理一些 dump 文件，比如说将堆栈打印出来等等

打印出来堆栈，我可以导入到聚类算法里面，找到其中崩溃堆栈最多的，重点对其进行处理。或者进行一些时间段异常监控

尽管我在开始时说实际用途不大，但用途不大不代表没有用途。整套玩下来，还是能够减少一点工作量的，且能够带来一丁点的收益的。比如说通过本文介绍的方式，我将海量的 dump 文件的堆栈打印出来，通过聚类算法获取到了，大量的 dump 都是无用的 dump 文件。因为大量的崩溃都是事后现场，即进入了最终崩溃点，非发生异常的点，或者异常发生点是属于类似空异常的类型，没有可用信息。或者是内存溢出，内存不足等通用问题。其他的有用的占比不到百分之一，在这里面就基本归类于用户环境问题占了大半，另一半就是调用的其他团队提供的 C++ 库。用户环境问题中，显卡驱动问题占比居多，这部分带来了确实有用的信息。其次的环境问题是比较杂项的，如第三方注入问题、输入法带崩问题、某些系统组件坏掉。用户环境问题的输出监控还是有用的，但调用的其他团队提供的 C++ 库这个基本上就凉凉了，因为很多团队开发完成就解散了，人和代码都找不到，这些就只能用数据来和产品大佬砍需求了，或者申请资源给他用 C# 代码重写了，或者是考虑跨进程调用了

通过分析用户问题，根据时间加入分析，可以了解到趋势信息。比如说最近某段时间内发现用户环境问题中，在崩溃堆栈里面，关于 Intel 显卡驱动的上升。可以进一步关注是否最近 Intel 的最新显卡驱动更新出现问题，取其中的 dump 文件，通过内部合作渠道反馈给到厂商，请厂商尽快修复问题。再比如最近某段时间内发现某个系统组件出现较高的崩溃率，可进一步关注微软系统更新，如果发现系统更新投毒了，那再给微软反馈一下，让微软修修。通过了解趋势信息可以辅助定位第三方影响问题，不仅包括直接厂商，如 Intel 和微软的，也包括第三方厂商尽管上文提到说内存溢出问题用途不大，但是如果带上软件版本号，可能通过趋势分析也是有点用途的。比如说发现了某个版本的内存溢出问题比其他版本高很多，再经一步调查，也许可以看到某个版本引入了某些奇特的逻辑，确实是软件自身的问题，而不是用户环境带来的内存不足问题

内存溢出问题如果发现是某段时间内有很多内存溢出问题，且所有软件版本都升高，那就可能也是第三方影响问题。比如之前调查到的 Intel 或微软的 D3D9On12 部分存在内存溢出问题，导致了大量应用都会多占用更多内存，从而出现内存溢出

但无论如何，本文介绍的这个自动化分析方法都无法百分百减少工作量，只能是辅助作用。本文介绍的自动化分析方法比较适合用在有大量的 dump 文件，人工调试不过来的情况，如果本身团队规模比较小，那就只能用于满足领导们的汇报需求了，比如用于吹质量设计

在 windbg 工具中，可以使用 -c 参数带上脚本文件，大概的命令行格式如下

windbg.exe -z [DUMP文件] -logo [日志输出文件] -c "$<[脚本文件]"

一般来说会先组织工作文件夹，将 dump 文件、脚本文件，以及将要被输出的日志文件都放在一个文件夹里面，将这个文件夹当成工作文件夹。如此即可简化命令行，如在 cmd 里通过 cd 命令进入到工作文件夹里面，再执行命令。如以下命令将分析 lindexi.dmp 文件，输出到 log.txt 里面，采用 script.txt 文件作为脚本

windbg.exe -z lindexi.dmp -logo log.txt -c "$<script.txt"

如在 C# 代码里面，可以在 Process 时指定工作路径，例子的代码如下

        Process.Start(new ProcessStartInfo("windbg.exe")
        {
            WorkingDirectory = @"C:\lindexi\Works",
            Arguments = "-z lindexi.dmp -logo log.txt -c \"$<script.txt\""
        });

上述代码的 -c 参数后面可以带上执行命令，也可以带上放入执行命令的脚本文件。对于比较复杂的，比较多条的命令，推荐放在脚本文件里面。在 windbg 里面，通过 $< 等前缀识别传入的是脚本文件而不是执行命令

接下来我将告诉大家如何编写这个脚本文件

脚本文件的格式非常简单，就是一行一句命令

根据分析 dotnet 应用的知识，对于 .NET Core 系框架，包括 dotnet 6 和 dotnet 7 和 dotnet 8 和 dotnet 9 等版本，第一步咱应该加载 sos.dll 文件。加载 sos.dll 的方法请参阅 WinDbg 加载 dotnet core 的 sos.dll 辅助调试方法

值得特别说明的是，默认的 dotnet-sos 工具存放的是 x64 的 sos.dll 文件，如果将要分析 dump 的应用是 x86 版本的，还需要更改 .load 的路径。比如我这里是放在 C:\Users\lindexi\.dotnet\tools\.store\dotnet-sos\8.0.510501\dotnet-sos\8.0.510501\tools\net6.0\any\win-x86\sos.dll 路径的

完成加载之后，即可使用 !analyze -v 强大的命令进行自动的分析，这一步能够输出异常等信息出来，非常好用。缺点只是分析时间比较长。如果是自动分析的话，挂着让其慢慢分析就不怕分析速度太慢了

接着使用 !clrstack 命令打印出来 dotnet 的托管堆栈，有时候可以在这里看到具体是哪个模块调用的。以及带上 ~*k 输出更多线程堆栈信息和可选加上 ~*e!clrstack 输出所有线程的托管调用堆栈

最后加上 qq 命令，让 windbg 自行退出。于是执行脚本的时候就可以在分析完成之后自动退出

根据上文编写的简单脚本代码如下

.load C:\Users\lindexi\.dotnet\tools\.store\dotnet-sos\8.0.510501\dotnet-sos\8.0.510501\tools\net6.0\any\win-x86\sos.dll
.echo ==============start=============
!analyze -v
!clrstack
~*k
.echo ==============end=============
qq

可以看到以上脚本带上了 .echo ==============start============= 等命令，这些命令只是为了在日志文件里面输入一些标识，方便后续咱编写代码读取日志文件，获取到一些 !analyze -v 和 !clrstack 命令输出的信息。完成以上步骤，接下来就是按照自己的喜好，编写一些 C# 逻辑，让 WinDbg 跑起来，自动分析 dump 文件。然后读取分析结果的日志文件，分析日志文件里面的内容。如此就完成了自动编写 DUMP 分析工具平台了。额外的，在现实使用中，可能还会带上 -y 参数，用于指定符号文件夹，减少加载符号时，拉取符号的耗时，参数是 -y [符号文件夹] 的格式