中小研发团队架构实践之生产环境诊断工具WinDbg
生产环境偶尔会出现一些异常问题,WinDbg或GDB是解决此类问题的利器。调试工具WinDbg如同医生的听诊器,是系统生病时做问题诊断的逆向分析工具,Dump文件类似于飞机的黑匣子,记录着生产环境程序运行的状态。本文主要介绍了调试工具WinDbg和抓包工具ProcDump的使用,并分享一个真实的案例。N年前不知谁写的代码,导致每一两个月偶尔出现CPU飙高的现象。我们先使用ProcDump在生产环境中抓取异常进程的Dump文件,然后在不了解代码的情况下通过WinDbg命令进行分析,最终定位到有问题的那行代码。
WinDbg是在Windows平台下的、强大的用户态和内核态调试工具。相比较于Visual Studio,它是一个轻量级的调试工具,所谓轻量级指的是它的安装文件大小较小,但是其调试功能,却比VS更为强大。它的另外一个用途是可以用来分析Dump数据。WinDbg是Microsoft公司免费调试器调试集合中的GUI的调试器,支持Source和Assembly两种模式的调试。WinDbg不仅可以调试应用程序,还可以进行Kernel Debug。结合Microsoft的Symbol Server,可以获取系统符号文件,便于应用程序和内核的调试。WinDbg支持的平台包括x86、IA64、AMD64。虽然WinDbg也提供图形界面操作,但它最强大的地方还是有着强大的调试命令,一般情况会结合GUI和命令行进行操作,常用的视图有:局部变量、全局变量、调用栈、线程、命令、寄存器、白板等。其中“命令”视图是默认打开的。
DebugDiag最初是为了帮助分析IIS的性能问题而开发的,它同样可以用于任何其他的进程。DebugDiag工具主要用于帮助解决如挂起、 速度慢、 内存泄漏或内存碎片,和任何用户模式进程崩溃等问题。该工具包括附加调试脚本,侧重于互联网信息服务(IIS)应用程序、 Web数据访问组件、 COM+和相关Microsoft技术、SharePoint和.NET。它提供可扩展对象模型中的COM对象的形式,并具有一个内置的报告框架提供的脚本主机。它由3 部分组成,包括调试服务、 调试器主机和用户界面。
ProcDump是System Internal提供的一个专门用来监测程序CPU高使用率从而生成进程Dump文件的工具。ProcDump可以根据系统的CPU使用率或者指定的性能计数器来针对特定进程生成一系列的Dump文件,以便调试者对事故原因进行分析。
- 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】
有以下四种方式获取Dump文件,具体如下:
现在重点介绍通过ProcDump抓取异常线程Dump文件,使用方法如下:
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]
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文件:
- 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。
操作步骤如下:
符号表是WinDbg关键的“数据库”,如果没有它,WinDbg基本上就是个废物,无法分析更多问题。所以使用WinDbg设置符号表,是必须要走的一步。
a、运行WinDbg软件,然后按【Ctrl+S】弹出符号表设置窗。
b、将符号表地址:SRV*C:\Symbols*http://msdl.microsoft.com/download/symbols 粘贴在输入框中,点击确定即可。点击确定之前,请先确认红色字的文件夹是否已被新建。
注:红色字表示符号表本地存储路径,建议固定路径,可避免符号表重复下载。
当你拿到一个Dump文件后,可使用【Ctrl+D】快捷键来打开一个Dump文件,或者点击WinDbg界面上的【File=>Open Crash Dump...】按钮,来打开一个Dump文件。第一次打开Dump文件时,可能会收到如下提示,出现这个提示时,勾选“Don't ask again in this WinDbg session”,然后点否即可。
当你想打开第二个Dump文件时,可能因为上一个分析记录未清除,导致无法直接分析下一个Dump文件,此时你可以使用快捷键【Shift+F5】来关闭上一个对Dump文件的分析记录。
分享一个数据库连接超时的Dump案例的分析过程:
当你打开一个Dump文件后,可能因为太多信息,让你无所适从,不过没关系,我们只需要关注几个关键信息就可以了。
加载SOS之前,先确定SOS的位置和版本,确定方法如下:
如果安装了Visual Studio,那么先按照如下步骤打开VS的命令行:
然后,在打开的VS命令行中输入【where sos.dll】,使获得SOS的位置和版本:
确定完SOS位置和版本号后,开始加载SOS扩展命令:
.load C:\Windows\Microsoft.NET\Framework64\v4.0.30319\SOS.dll
如下图所示:
如下图所示:
如下图所示:
综合以上分析可以大胆地猜测Common.cs 中第16行“Data Source=***;Initial Catalog=***;Persist Security Info=True;User ID=sa;Password=***”的这个数据库连接字符串应该有问题,然后到代码中相应的地方进一步确认和修改就可以了。
分享笔者工作过的一家公司某业务系统CPU飙高90%以上的Dump分析过程案例,步骤如下:
.load C:\Windows\Microsoft.NET\Framework\v2.0.50727\sos.dll
执行!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分析除了需要懂得几个命令之外,经验更加重要,最后再补充两点:
- WinDbg不是专门用于调试.NET程序的工具,它更偏向于底层,可用于内核和驱动调试,特别是对于某些相当疑难的问题调试有所帮助,例如内存泄漏等问题。进行普通的.NET程序调试还是使用微软专为.NET开发所提供的调试工具更方便一些。
- SOS扩展命令中最有用的命令是!help,使用该命令可以列出所有可用的SOS扩展命令列表,使用!help [SOSCommandName]可以查看每一个具体扩展命令的详细使用说明。例如!help dumpheap就可以查看!dumpheap这个扩展命令的具体使用方法。多多利用!help命令可以很快上手SOS。
- WinDbgTest下载地址:https://github.com/das2017/WinDbgTest
- WinDbg官网:http://www.windbg.org/
- ProcDump v9.0官网:https://technet.microsoft.com/en-us/sysinternals/dd996900.aspx
posted on 2019-01-03 12:17 arch-system 阅读(4783) 评论(12) 编辑 收藏 举报