中小研发团队架构实践之生产环境诊断工具WinDbg

生产环境偶尔会出现一些异常问题，WinDbg或GDB是解决此类问题的利器。调试工具WinDbg如同医生的听诊器，是系统生病时作问题诊断的逆向分析工具，Dump文件相似于飞机的黑匣子，记录着生产环境程序运行的状态。本文主要介绍了调试工具WinDbg和抓包工具ProcDump的使用，并分享一个真实的案例。N年前不知谁写的代码，致使每一两个月偶尔出现CPU飙高的现象。咱们先使用ProcDump在生产环境中抓取异常进程的Dump文件，而后在不了解代码的状况下经过WinDbg命令进行分析，最终定位到有问题的那行代码。

1、诊断工具简介

1.1 WinDbg

WinDbg是在Windows平台下的、强大的用户态和内核态调试工具。相比较于Visual Studio，它是一个轻量级的调试工具，所谓轻量级指的是它的安装文件大小较小，可是其调试功能，却比VS更为强大。它的另一个用途是能够用来分析Dump数据。WinDbg是Microsoft公司免费调试器调试集合中的GUI的调试器，支持Source和Assembly两种模式的调试。WinDbg不只能够调试应用程序，还能够进行Kernel Debug。结合Microsoft的Symbol Server，能够获取系统符号文件，便于应用程序和内核的调试。WinDbg支持的平台包括x8六、IA6四、AMD64。虽然WinDbg也提供图形界面操做，但它最强大的地方仍是有着强大的调试命令，通常状况会结合GUI和命令行进行操做，经常使用的视图有：局部变量、全局变量、调用栈、线程、命令、寄存器、白板等。其中“命令”视图是默认打开的。

1.2 DebugDiag

DebugDiag最初是为了帮助分析IIS的性能问题而开发的，它一样能够用于任何其余的进程。DebugDiag工具主要用于帮助解决如挂起、 速度慢、 内存泄漏或内存碎片，和任何用户模式进程崩溃等问题。该工具包括附加调试脚本，侧重于互联网信息服务（IIS）应用程序、 Web数据访问组件、 COM+和相关Microsoft技术、SharePoint和.NET。它提供可扩展对象模型中的COM对象的形式，并具备一个内置的报告框架提供的脚本主机。它由3 部分组成，包括调试服务、 调试器主机和用户界面。

1.3 ProcDump

ProcDump是System Internal提供的一个专门用来监测程序CPU高使用率从而生成进程Dump文件的工具。ProcDump能够根据系统的CPU使用率或者指定的性能计数器来针对特定进程生成一系列的Dump文件，以便调试者对事故缘由进行分析。

2、诊断工具下载

• WinDbg x86位版本下载：【http://download.microsoft.com/download/A/6/A/A6AC035D-DA3F-4F0C-ADA4-37C8E5D34E3D/setup/WinSDKDebuggingTools/dbg_x86.msi】

• WinDbg x64位版本下载：【http://download.microsoft.com/download/A/6/A/A6AC035D-DA3F-4F0C-ADA4-37C8E5D34E3D/setup/WinSDKDebuggingTools_amd64/dbg_amd64.msi】

• DebugDiag v2下载：【https://www.microsoft.com/en-us/download/details.aspx?id=49924】

• ProcDump v9.0下载：【https://download.sysinternals.com/files/Procdump.zip】

3、获取异常进程的Dump文件

有如下四种方式获取Dump文件，具体以下：

3.1 经过【任务管理器】获取Dump文件，这样获取的是MinDump

3.2 利用WinDbg的adplus获取Dump文件，这样获取的是FullDump

3.3 经过DebugDiag建立.NET异常转储Dump文件

 

 

3.4 经过ProcDump抓取异常线程Dump文件

如今重点介绍经过ProcDump抓取异常线程Dump文件，使用方法以下：

a. 命令行：

procdump [-a] [[-c|-cl CPU usage] [-u] [-s seconds]] [-n exceeds] [-e [1 [-b]] [-f <filter,...>] [-g] [-h] [-l] [-m|-ml commit usage] [-ma | -mp] [-o] [-p|-pl counter threshold] [-r] [-t] [-d <callback DLL>] [-64] <[-w] <process name or service name or PID> [dump file] | -i <dump file> | -u | -x <dump file> <image file> [arguments] >] [-? [ -e]

b. 实例：

procdump -c 70 -s 5 -ma -n 3 w3wp

当系统CPU使用率持续5秒超过70%时，连续抓3个Full Dump。

procdump outlook -p "\Processor(_Total)\% Processor Time" 80

当系统CPU使用率超过80%，抓取Outlook进程的Mini Dump。

procdump -ma outlook -p "\Process(Outlook)\Handle Count" 10000

当Outlook进程Handle数超过10000时抓取Full Dump

procdump -ma 4572

直接生成进程号为4572的Full Dump。

 

下图是在WindgbHighCpu进程中形成High CPU时运行ProcDump命令的运行效果，能够看到在CPU每次持续5秒达到5%后就会生成相应的Dump文件，共生成了3份Full Dump文件：

c. 注意：

• ProcDump须要进程已经启动，而且中途不能中止。好比须要抓取IIS Worker Process的High CPU Dump，因为IIS Worker Process默认会配置Idle Timeout = 20 min，即该进程在20分钟内没有任何请求的话就会自动结束，这种状况下ProcDump也会自动结束。须要从新运行命令。所以若是目标程序存在这样的配置，须要暂时将该配置取消。

• 有些系统管理员但愿可以运行该工具后退出用户session，ProcDump是作不到的，若是有这种需求能够考虑使用DebugDiag。

• 在调试High CPU问题的时候常常用到的一个命令是!runaway，可是有些时候!runway在ProcDump抓取Dump文件的过程当中运行不出来，报错信息以下：

0:000> !runaway ERROR: !runaway: extension exception 0x80004002. "Unable to get thread times - dumps may not have time information"

解决的方法是将Debugging Tools for Windows (WinDbg)安装目录下的dbghelp.dll拷贝到procdump.exe所在目录下，而后再运行命令抓取Dump。 

4、WinDbg使用方法

操做步骤以下：

4.1 抓取异常程序的Dump文件

4.2 设置符号表

符号表是WinDbg关键的“数据库”，若是没有它，WinDbg基本上就是个废物，没法分析更多问题。因此使用WinDbg设置符号表，是必需要走的一步。

a、运行WinDbg软件，而后按【Ctrl+S】弹出符号表设置窗。

b、将符号表地址：SRV*C:\Symbols*http://msdl.microsoft.com/download/symbols 粘贴在输入框中，点击肯定便可。点击肯定以前，请先确认红色字的文件夹是否已被新建。

注：红色字表示符号表本地存储路径，建议固定路径，可避免符号表重复下载。

4.3 学会打开第一个Dump文件

       

 

当你拿到一个Dump文件后，可以使用【Ctrl+D】快捷键来打开一个Dump文件，或者点击WinDbg界面上的【File=>Open Crash Dump...】按钮，来打开一个Dump文件。第一次打开Dump文件时，可能会收到以下提示，出现这个提示时，勾选“Don't ask again in this WinDbg session”，而后点否便可。

当你想打开第二个Dump文件时，可能由于上一个分析记录未清除，致使没法直接分析下一个Dump文件，此时你可使用快捷键【Shift+F5】来关闭上一个对Dump文件的分析记录。

4.4 经过简单的几个命令学会分析Dump文件

分享一个数据库链接超时的Dump案例的分析过程：

当你打开一个Dump文件后，可能由于太多信息，让你无所适从，不过不要紧，咱们只须要关注几个关键信息就能够了。

a. 加载SOS扩展命令

加载SOS以前，先肯定SOS的位置和版本，肯定方法以下：

若是安装了Visual Studio，那么先按照以下步骤打开VS的命令行：

而后，在打开的VS命令行中输入【where sos.dll】，使得到SOS的位置和版本：

 

肯定完SOS位置和版本号后，开始加载SOS扩展命令：

.load C:\Windows\Microsoft.NET\Framework64\v4.0.30319\SOS.dll

以下图所示：

b. 使用!clrstack命令来查看当前的调用堆栈信息

以下图所示：

c. 使用!dso命令来查看堆栈上的全部对象详细信息

以下图所示：

综合以上分析能够大胆地猜想Common.cs 中第16行“Data Source=***;Initial Catalog=***;Persist Security Info=True;User ID=sa;Password=***”的这个数据库链接字符串应该有问题，而后到代码中相应的地方进一步确认和修改就能够了。        

5、一个真实案例

分享笔者工做过的一家公司某业务系统CPU飙高90%以上的Dump分析过程案例，步骤以下：

5.1 使用ProcDump抓包

5.2 加载SOS扩展命令

.load C:\Windows\Microsoft.NET\Framework\v2.0.50727\sos.dll

5.3 分析

执行!runaway命令，查看线程使用CPU时间状况，以下图所示。着重分析前面几个线程。 

执行~22s命令，进入到线程22，以下图所示：

执行!clrstack命令查看当前线程堆栈变量值的信息，从图中能够猜出大概是ExecuteNonQuery()这方法有点问题，以下图所示：

再执行!dso命令能够查看堆栈上的全部对象详细信息，以下图所示：

从图中看，形成CPU飙高的罪魁祸首多半由SQL Server执行

INSERT INTO [dbo].[tbl_Interface_ProcessLog] (IKey,Username,ClientIP,Module,OrderNo,LogType,Content) VALUES (@IKey,@Username,@ClientIP,@Module,@OrderNo,@LogType,@Content)

这条语句时产生异常引发，而后到源代码中找出相应的语句，通过进一步的确认、修改和从新发布后就解决了CPU飙高的问题。

 

至此，掌握几个简单的WinDbg命令以后，基本上绝大多数Dump你们均可以独立分析了。固然WinDbg是个强大的工具，同时产生CPU飙高和内存泄漏的缘由也有不少。若是想分析得足够准确，那么就只有多学多练，多去分析。由于掌握WinDbg分析除了须要懂得几个命令以外，经验更加剧要，最后再补充两点：

1. WinDbg不是专门用于调试.NET程序的工具，它更偏向于底层，可用于内核和驱动调试，特别是对于某些至关疑难的问题调试有所帮助，例如内存泄漏等问题。进行普通的.NET程序调试仍是使用微软专为.NET开发所提供的调试工具更方便一些。

1. SOS扩展命令中最有用的命令是!help，使用该命令能够列出全部可用的SOS扩展命令列表，使用!help [SOSCommandName]能够查看每个具体扩展命令的详细使用说明。例如!help dumpheap就能够查看!dumpheap这个扩展命令的具体使用方法。多多利用!help命令能够很快上手SOS。

6、Demo下载及更多资料

• WinDbgTest下载地址：https://github.com/das2017/WinDbgTest

• WinDbg官网：http://www.windbg.org/

• ProcDump v9.0官网：https://technet.microsoft.com/en-us/sysinternals/dd996900.aspx