面向.Net程序员的dump分析

时间 2019-11-07

原文原文链接

背景程序员

　　Dump文件是进程的内存镜像。能够把程序的执行状态经过调试器保存到dump文件中。在 Windows 系统上， dump 文件分为内核 dump 和用户态 dump 两种。前者通常用来分析内核相关的问题，好比驱动程序；后者通常用来分析用户态程序的问题。shell

　　通常的程序员可能接触不到dump文件，反而是运维会用的多一些。不过若是你抗战在第一线，学会dump的分析无疑是掌握一柄利器。由于不少场景下，在线下的单元测试或者性能测试中因为测试用例的不充分或者生产与测试环境的硬件以及pv量级的不一样等等状况致使问题暴露不出，而在生产环境中又没有足够的日志或者堆栈信息来指向问题产生的缘由。这个时候dump文件的分析就显得颇有做用。服务器

　　正文分3节抓取dump以及dump的手动和自动分析。对于初学者自动分析dump是很方便的一种渠道。框架

一. 抓取dump运维

　　1. 最简单的方法经过任务管理器工具

　　2. 经过debugdiag性能

　　debugdiag是一个微软提供的dump抓取和分析工具。能够创建各类规则在不一样的条件下抓取dump，同时具备强大的dump分析功能。单元测试

　　下载地址：http://www.microsoft.com/en-us/download/details.aspx?id=26798测试

　　3. Adplus方式字体

　　运行 cmd ，进入 adplus.exe 文件所在目录，运行以下命令：
　　单个进程： adplus .exe – hang – p <PID> – o d: ¥
　　多个进程： adplus .exe – hang – p <PID1> -p <PID2> – o d: ¥
　　Mini Dump ： adplus .exe - MiniOnSecond – hang – p <PID> – o d: ¥　

　　抓取方式的选择：

　　任务管理器的抓取适合dump文件不大，对应系统盘默认存放路径的空间彻底足够的状况。

　　debugdiag的抓取能够适应多种状况，经过工具的配置来完成。

　　Adplus解决了任务管理器抓取方式的限制，能够处理对应多个进程大文件的状况。

二. dump的手动分析

　　工具： winbdg

　　WinDBG不是专门用于调试.Net程序的工具，它更偏向于底层，可用于内核和驱动调试。进行普通的.Net程序调试仍是使用微软专为.Net开发的调试工具MDBG更方便一些。可是WinDBG能看到更多的底层信息，对于某些特别疑难的问题调试有所帮助，例如内存泄漏等问题。

　　工具下载： WinBdgTool.zip

　　测试代码下载： MyDumpTest.7z

　　首先添加设定符号文件路径（Symbol Path）,当你使用Visual Studio编译程序时，是否有留意到在bin/Debug文件夹下会有.pdb后缀的文件？这些文件包含有dll程序集的调试符号，pdb文件并不包含有执行代码，只是使调试工具能把代码执行指令翻译为正确的可识别字符。微软提供了包含大量pdb文件的公共服务器，地址以下：http://msdl.microsoft.com/download/symbols。打开windbg程序，选择“File->Symbol File Path…“，把下面的内容复制进去保存。srv*c:\temp*http://msdl.microsoft.com/download/symbols。

　　下面这行命令若是你发现出现Unable to verify checksum...或者的消息那是由于你没有添加.net的sos扩展或者sos的版本没有对应上。.Net1.1时代的SOS扩展已经自带于下载安装的WinDBG中，从.Net2.0之后，SOS扩展已经自带到.Net框架中：C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\SOS.dll，为了避免至于引发混淆，最好的方法就是使用前面的loadby调试器元命令来让WinDBG本身决定加载什么版本的SOS。

　　添加sos：.load C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\sos.dll。

　　加载SOS后，使用命令.chain来查看调试链中是否已经成功包含SOS扩展。

　　经过!eeversion查看sos的版本号。

　　实战命令： ~ 查看线程

　　这代表当前dump里记录的线程数。若是要切换线程，用波浪线+序号+s来切换，如切换到线程2，那么用～2s便可。

　　lm 查看你加载的模块

　　kb 查看native code调用栈

　　用~如今只有线程信息，对于每一个线程，在被抓的那一刻，在执行什么，咱们有命令：kb。

　　看到clr你们应该很眼熟吧。这里已经能够看到较详细的调试信息了。

　　!runaway (查看线程对应 CPU 运行时间)

　　由于咱们的测试程序是测试的是线程阻塞因此咱们选一个运行时间为0的，例如415

　　!dso 查看这个堆栈中的对象

　　!clrstack 查看这个线程的托管代码调用栈

　　经过上面咱们已经能够看出这个线程一直都是处于阻塞状态。

　　到这里基本上一个小的测试程序能够告一段落了，固然windbg的功能远远不止如此，这里分享一些资源给你们。

　　资源下载： WinDbg入门.rar Windbg用法详解.7z

三. dump的自动分析

　　1. debugdiag

　　这里有几种规则类型的选择，通常咱们经常使用的用crash来查看锁和堵塞的状况，performance来检查性能的问题。

　　选择完成后直接点击开始分析

　　生成报表

　　查看描述

　　点击详细

　　这样，红色字体就是问题的所在。而后根据具体问题下发到对应开发部门解决。

　　2. Hang自动化分析

　　在WinDbg输入以下命令

　　.shell -ci "~* kb;.echo MANAGED THREADS;!threads;.echo MANAGED CALLSTACKS;~* e !clrstack;" D:\xx.exe

　　本篇先到此但愿对你们有帮助