windbg

时间：2018-11-09 11:14 来源：免费论文网

篇一：windbg调试dmp

如何根据程序崩溃时的DMP文件使用WinDbg查找调用堆栈

HOW TO：查找问题的异常堆栈时出现的 UnhandledExceptionFilter 调用堆栈跟踪中 http://support.microsoft.com/kb/313109/zh-cn

察看本文应用于的产品

本页

概要

使用 Windbg.exe 打开转储文件

使用 Windbg.exe 确定异常堆栈

参考

展开全部 | 关闭全部

概要

没有异常处理程序定义处理引发的异常时，将调用该 UnhandledExceptionFilter 函数。通常，该函数会将异常传递给在 Ntdll.dll 为文件其中捕获，并尝试处理设置。

在进程的内存快照所在某些情况下，可以看到锁定点保存到线程的线程的调用 UnhandledExceptionFilter 函数。在这的种情况下您可以按照本文以确定导致此异常的 DLL。

回到顶端

使用 Windbg.exe 打开转储文件

下载并安装调试程序。要下载调试程序，请访问下面的 Microsoft 网站：

Microsoft 调试工具

/whdc/devtools/ddk/default.mspx

(/whdc/devtools/ddk/default.mspx)

打开安装调试程序，文件夹，然后双击 Windbg.exe 启动调试器。

在文件菜单上单击打开的崩溃转储（或按 Ctrl+D），然后选择要查看该转储文件。回到顶端

使用 Windbg.exe 确定异常堆栈

在 Windbg.exe，打开进程的.dmp 文件。

请确保您符号路径指向正确的位置。有关如何执行此操作，请访问下面的 Microsoft Web 站点：

如何获得符号

/whdc/devtools/ddk/default.mspx

(/whdc/devtools/ddk/default.mspx)

在命令提示符下键入 ~ * kb 以列出所有进程中的线程。

标识对函数调用的线程 Kernel32! UnhandledExceptionFilter 。它类似于以下：

120 id: f0f0f0f0.a1cSuspend: 1 Teb 7ff72000 Unfrozen

ChildEBP RetAddr Args to Child

09a8f334 77eb9b46 0000244c 00000001 00000000 ntdll!ZwWaitForSingleObject+0xb

[i386\usrstubs.asm @ 2004]

09a8f644 77ea7e7a 09a8f66c 77e861ae 09a8f674 KERNEL32!UnhandledExceptionFilter+0x2b5

[D:\nt\private\windows\base\client\thread.c @ 1753]

09a8ffec 00000000 787bf0b8 0216fe94 00000000 KERNEL32!BaseThreadStart+0x65

[D:\nt\private\windows\base\client\support.c @ 453]

切换到该线程（在本例中，该线程是"~120s"）。

在第一个参数的指定位置显示内存内容 Kernel32! UnhandledExceptionFilter 通过添加第一个参数。此指向 EXCEPTION_POINTERS 结构

0:120> dd 09a8f66c

09a8f66c 09a8f738 09a8f754 09a8f698 77f8f45c

09a8f67c 09a8f738 09a8ffdc 09a8f754 09a8f710

09a8f68c 09a8ffdc 77f8f5b5 09a8ffdc 09a8f720

09a8f69c 77f8f3fa 09a8f738 09a8ffdc 09a8f754

09a8f6ac 09a8f710 77e8615b 09a8fad4 00000000

09a8f6bc 09a8f738 74a25336 09a8f6e0 09a8f910

09a8f6cc 01dc8ad8 0d788918 00000001 018d1f28

09a8f6dc 00000001 61746164 7073612e 09a8f71c

第一个 DWORD 代表异常记录。若要获取有关异常的类型信息，请请在命令提示符处运行以下：

.exr first DWORD from step 6

0:120> .exr 09a8f738

ExceptionAddress: 78011f32 (MSVCRT!strnicmp+0x00000092)

ExceptionCode: c0000005

ExceptionFlags: 00000000

NumberParameters: 2

Parameter[0]: 00000000

Parameter[1]: 00000000

Attempt to read from address 00000000

第二个 DWORD 是上下文记录。若要获取上下文的信息，请在命令提示符处运行以下：

.cxr second DWORD from step 6

0:120> .cxr 09a8f754

eax=027470ff ebx=7803cb28 ecx=00000000 edx=00000000 esi=00000000 edi=09a8fad4 eip=78011f32 esp=09a8fa20 ebp=09a8fa2c iopl=0nv up ei ng nz na po nc

cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010286 MSVCRT!strnicmp+92:

78011f32 8a06 mov al,[esi]

运行 kv 命令获得实际的异常的调用堆栈。这有助于您识别可能未被处理正确的过程中实际问题

0:120> kv

ChildEBP RetAddr Args to Child

WARNING: Stack unwind information not available. Following frames may be wrong.

09a8fa2c 780119ab 09a8fad4 00000000 09a8faa8 MSVCRT!strnicmp+0x92

09a8fa40 7801197c 09a8fad4 00000000 6d7044fd MSVCRT!stricmp+0x3c

09a8fa80 6e5a6ef6 09a8fad4 2193d68d 00e5e298 MSVCRT!stricmp+0xd

09a8fa94 6d7043bf 09a8fad4 09a8faa8 0000001c IisRTL!CLKRHashTable::FindKey+0x59 (FPO:

[2,0,1])

09a8faac 749fc22d 09a8fad4 01d553b0 0000001c ISATQ!CDirMonitor::FindEntry+0x1e (FPO: [Non-Fpo]) [D:\nt\private\inet\iis\svcs\infocomm\atq\dirmon.cpp @ 884]

09a8fac4 749fd1cb 09a8fad4 09a8fb10 525c3a46 asp!RegisterASPDirMonitorEntry+0x6e (FPO: [EBP 0x09a8fb08] [2,0,4]) [D:\nt\private\inet\iis\svcs\cmp\asp\aspdmon.cpp @ 534]

09a8fb08 749fcdd6 00000000 09a8fcbc 018d1f28 asp!CTemplateCacheManager::RegisterTemplateForChangeNotification+0x8a

(FPO: [Non-Fpo]) [D:\nt\private\inet\iis\svcs\cmp\asp\cachemgr.cpp @ 621]

09a8fb3c 74a08bfe 00000000 000000fa 74a30958 asp!CTemplateCacheManager::Load+0x382 (FPO: [Non-Fpo]) [D:\nt\private\inet\iis\svcs\cmp\asp\cachemgr.cpp @ 364]

09a8fc68 74a0d4c9 04c12518 018d1f28 09a8fcbc asp!LoadTemplate+0x42

(FPO: [Non-Fpo]) [D:\nt\private\inet\iis\svcs\cmp\asp\exec.cpp @ 1037]

09a8fcc0 74a2c3e5 00000000 0637ee38 09a8fd58 asp!CHitObj::ViperAsyncCallback+0x3e8 (FPO: [Non-Fpo]) [D:\nt\private\inet\iis\svcs\cmp\asp\hitobj.cpp @ 2414]

09a8fcd8 787c048a 00000000 77aa1b03 01e91ed8 asp!CViperAsyncRequest::OnCall+0x3f (FPO: [Non-Fpo]) [D:\nt\private\inet\iis\svcs\cmp\asp\viperint.cpp @ 194]

09a8fce0 77aa1b03 01e91ed8 77a536d8 00000000 COMSVCS!STAActivityWorkHelper+0xa (FPO: [1,0,0])

09a8fd24 77aa1927 000752f8 000864dc 787c0480 ole32!EnterForCallback+0x6a

(FPO: [Non-Fpo]) [D:\nt\private\ole32\com\dcomrem\crossctx.cxx @ 1759]

09a8fe50 77aa17ea 000864dc 787c0480 01e91ed8 ole32!SwitchForCallback+0x12b

(FPO: [Non-Fpo]) [D:\nt\private\ole32\com\dcomrem\crossctx.cxx @ 1644]

09a8fe78 77aa60c1 000864dc 787c0480 01e91ed8 ole32!PerformCallback+0x50

(FPO: [Non-Fpo]) [D:\nt\private\ole32\com\dcomrem\crossctx.cxx @ 1559]

09a8fed4 77aa5fa6 04f2b4c0 787c0480 01e91ed8 ole32!CObjectContext::InternalContextCallback+0xf5

(FPO: [Non-Fpo]) [D:\nt\private\ole32\com\dcomrem\context.cxx @ 3866]

09a8fef4 787bd3c3 04f2b4c0 787c0480 01e91ed8 ole32!CObjectContext::DoCallback+0x1a (FPO: [Non-Fpo]) [D:\nt\private\ole32\com\dcomrem\context.cxx @ 3746]

09a8ff24 787bf373 0216fb3c 00000007 09a8ffec COMSVCS!STAActivityWork::DoWork+0x73 (FPO: [0,4,2])

09a8ffb4 77e8758a 0216fe94 0216fb3c 00000007 COMSVCS!STAThread::STAThreadWorker+0x2bb

(FPO: [EBP 0x09a8ffec] [1,31,4])

09a8ffec 00000000 787bf0b8 0216fe94 00000000 KERNEL32!BaseThreadStart+0x52 (FPO: [Non-Fpo]) [D:\nt\private\windows\base\client\support.c @ 451]

30.8 调试符号

在第25章中，我们详细地介绍了调试符号的概念、种类、产生过程和存储方式。本节将讨论如何在WinDBG调试器中使用调试符号，包括加载调试符号，设置调试符号选项以及解决有关的问题。

30.8.1 重要意义

调试符号（Debug Symbols）是调试器工作的重要依据，保证调试符号的准确对于调试器的正常工作非常重要。如果缺少调试符号或调试符号不匹配，那么调试器就可能显示出错误的结果。为了让大家对这一点有深刻的认识，我们先来看一个简单的例子。使用WinDBG（尚未设置符号路径）附加到一个记事本进程上，然后使用~0 s切换到0号线程，再输入k命令显示栈回溯信息，其结果如清单30-2所示。

清单30-2 没有调试符号时显示的栈回溯

0:000> k

*** ERROR: Module load completed but symbols could not be loaded for C:\…notepad.exe

ChildEBP RetAddr

WARNING: Stack unwind information not available. Following frames may be wrong.

0007fed8 01002a1b ntdll!KiFastSystemCallRet

0007ff1c 01007511 notepad+0x2a1b

*** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\...\kernel32.dll -

0007ffc0 7c816fd7 notepad+0x7511

0007fff0 00000000 kernel32!RegisterWaitForInputIdle+0x49

在上面的结果中，WinDBG报告了两个错误和一条警告，都与符号有关。第一个错误是告诉我们未能为notepad.exe加载符号。接下来的警告告诉我们因为缺少符号文件提供栈展开信息，所以其下各帧的信息可能是错误的。这个警告决不是空穴来风，看到了这样的警告，确实需要提高警惕，开始以怀疑的眼光观察其后的内容。例如最下面一行显示的函数名是kernel32.dll中的RegisterWaitForInputIdle函数。栈回溯结果的最下面一个栈帧对应的是当前线程的起始函数，这个函数名怎么会是线程的起始函数呢？键入.symfix c:\symbols命令设置符号文件的搜索路径（稍后将详细介绍这条命令），然后输入.reload加载符号，再次输入k命令的结果如清单30-3所示。

清单30-3 有调试符号时显示的栈回溯

0:000> k

ChildEBP RetAddr

0007feb8 7e4191ae ntdll!KiFastSystemCallRet

0007fed8 01002a1b USER32!NtUserGetMessage+0xc

0007ff1c 01007511 notepad!WinMain+0xe5

0007ffc0 7c816fd7 notepad!WinMainCRTStartup+0x174

0007fff0 00000000 kernel32!BaseProcessStart+0x23

这次的结果中没有任何错误和警告，是正确的结果。与这个结果相比，清单30-2中的显示不仅少了一个栈帧，而且显示出的四个栈帧中有三个都是不准确的，可见调试符号的重要性。

30.8.2 符号搜索路径

大多数调试任务都涉及到多个模块，因此需要加载很多个符号文件，而且这些符号文件很可能不在同一个位置上。为了方便调试，WinDBG允许用户指定一个目录列表，当需要加载符号文件时，WinDBG会从这些目录中搜索合适的符号文件。这个目录列表被称为符号搜索路径，简称符号路径（Symbol Path）。在符号路径中可以指定两类位置，一类是普通的磁盘目录或者网络共享目录的完整路径，另一类是符号服务器，多个位置之间使用分号分隔。例如，以下是一个典型的符号路径：

SRV*d:\symbols*http://msdl.microsoft.com/download/symbols;c:\work\debug;

第一个分号后面定义的是一个本地目录，前面定义的是符号服务器，我们稍后再详细介绍。可以有几种方法来设置符号路径。

n 设置环境变量_NT_SYMBOL_PATH和_NT_ALT_SYMBOL_PATH。

n 启动调试器（WinDBG）时，在命令行参数中通过-y开关来定义。

n 使用.sympath命令来增加、修改或者显示符号路径。如执行sympath + c:\folder2便将c:\folder2目录加入到符号搜索路径中。

n 使用.symfix命令来自动设置符号服务器（详见下文）。

n 使用WinDBG的GUI，通过File>Symbol File Path菜单打开Symbol Search Path对话框，然后通过图形界面进行设置。

执行不带任何参数的.sympath命令可以显示当前的符号路径。

30.8.3 符号服务器

无论是用户态调试，还是内核态调试，通常都涉及到很多个模块，而且不同的模块可能属于不同的开发部门或者公司，一个模块通常还会有很多个不同的版本，所以在调试时要为每个模块都找到正确的符号文件并不是一件简单的事。

解决以上问题的一个有效方法是使用符号服务器（Symbol Server）。简单来说，符号服务器就是用来存储调试符号文件的一个大文件库，调试器可以从这个文件库中读取指定特征（名称、版本等）的符号文件。图30-10画出了符号服务器的示意图，图中左侧是使用WinDBG调试器的工作机，右侧是符号服务器。

篇二：windbg

几个常用的WinDBG命令

转载，但没找到原始出处，sorry。

1. 查询符号

kd> x nt!KeServiceDescriptorTable*

8046e100 nt!KeServiceDescriptorTableShadow = <no type information> 8046e0c0 nt!KeServiceDescriptorTable = <no type information>kd> ln 8046e100

(8046e100)nt!KeServiceDescriptorTableShadow| (8046e140)nt!MmSectionExtendResource

Exact matches:（精确匹配）

nt!KeServiceDescriptorTableShadow = <no type information>

2. 下载系统文件的符号

symchk c:\winnt\system32\ntoskrnl.exe /s

srv*c:\symbols*http://msdl.microsoft.com/download/symbols SYMCHK: FAILED files = 0（用于验证符号文件或者从符号服务器下载符号文件的工具） SYMCHK: PASSED + IGNORED files = 1 （通过+被忽略的文件）

3. 查看 event 对象的信号状态

!object \BaseNamedObjects（！对象\ BaseNamedObjects）

dt -b nt!_KEVENT xxxxxxxx

4. 查看 LastError 值

!gle

5. 指定进制形式， 0x/0n/0t/0y 分别表示 16/10/8/2 进制 ? 0x12345678+0n10

Evaluate expression: 305419906 = 12345682 （求值|求表达式值）

6. 过滤命令窗口输出信息

.prompt_allow -reg +dis -ea -src -sym （命令控制在单步和跟踪时显示哪些信息，以及目标的执行何时停止）

7. .formats 命令

以多种格式显示表达式的值

0:000> .formats @eax

Evaluate expression:

Hex: 00181eb4 （十六进制的）

Decimal: 1580724（十进位的）

Octal:00006017264（八进制的）

Binary: 00000000 00011000 00011110 10110100（二进制）

Chars:....（字符）

Time: Mon Jan 19 15:05:24 1970

Float:low 2.21507e-039 high 0（浮点数）

Double: 7.80981e-318

8. 异常处理相关

有 sx, sxd, sxe, sxi, sxn, sxr 几条命令可用来设置异常和事件的处理方式。比如：

0:000> sxe ld

可以在加载 dll 时中断下来。

9. 内核调试时切换进程

lkd> !process 0 0

lkd> .process xxxxxxxx

10. 可在桌面上建立一个 WinDbg.exe 的快捷方式，然后在该快捷方式的属性力设置如下命令行

C:\WinDBG\windbg.exe -c ".prompt_allow +dis -reg -ea -src

-sym; .enable_unicode 1; .enable_long_status 1; .logopen /t

c:\dbglog\dbglog.txt" （. unicode, 在电脑上用 16 位元显示字符的代码 (同 ASCII 类似, 但是包括更大数量的字符并可以显示全世界所有语言的字符)）

11. 本机内核调试

通过 File/Kernel Debug… 菜单可以打开内核调试选择窗口，选择最后一个 Local 选项页，确定后可以以内核方式调试本地机器。这时所有会挂起系统的命令都用不了了，但可以读写系统内存。另外，有一个方便的用途是用来查看系统结构，比如： dt nt!_EPROCESS 。

12. 其他命令

windbg中常用的命令

~ - list threads in current process context（在当前进程列表线程上下文） ~* - list detail information of threads in current process context（列出当前进程中线程的详细信息，语境）

lm - list all loaded modules（列出所有加载的模块）

!sym noice/quiet - symbol prompts on/off（符号提示开/关）

.srcpath - set source code path（设置源代码路径）

k - display current stack（显示当前堆栈）

~*kb - display current stack for all threads（显示当前所有线程的堆栈） dv - display current local variable (ctrl + alt + v to switch mode)（显示当前局部变量）

.Frame - call stack（调用栈）

dt xxx - display data structure for xxx such as PEB（显示数据结构XXX的，如后烘）

!gle/!error - display last error for current thread（显示当前线程的最后一个错误）.

!teb - diplay current thread execution block（diplay当前线程执行块） !peb - diplay current process execution block（diplay当前进程执行块） r [@register] - display value of all register（diplay价值的所有寄存器） ln [Address] - display the object type in Address（在地址对象类型） x [] - search address for global variable or global function, such as "x kernel32!*"（搜索地址的全局变量或全局函数，如“× kernel32中！*”）

!locks - display dead lock（显示死锁）

!handle - get current handle usage（获取当前处理的使用）

!htrace [enable] - display and trace handles.（显示和跟踪处理） u – disassemble（分解）

bp [Kernel!SetLastError] [value] - set break pointer（设置断点特） bl - display break pointer information.（打破指针信息显示）

for example:

bp `mysource.cpp:143` "j (poi(MyVar)"0n20) ''; 'g' "

when MyVar is exceed 0x20, g command will be invoked. NOTE: "j" is to set conditional break pointer.

ba - data break pointer（数据打破指针）

ba w4 0x4000000 "kb;g" - list all modify 0x40000's call stack. （列出所有修改0x40000的调用堆栈）

p,pa,t,ta - control command （控制命令）

篇三：windbg工具使用

网维大师目前能够收集32位客户机系统（XP和

win7 32位）产生的蓝屏DMP文件到服务端DUMP文件夹，我们可以通过分析蓝屏曰志来确定到底是什么导致了客户机蓝屏。

一、WinDbg是什么？它能做什么？

WinDbg是在windows平台下，强大的用户态和内核态调试工具。它能够通过dmp文件轻松的定位到问题根源，可用于分析蓝屏、程序崩溃（IE崩溃）原因，是我们日常工作中必不可少的一个有力工具，学会使用它，将有效提升我们的问题解决效率和准确率。

二、WinDbg6.12.0002.633下载：

x86位版本下载：【微软官方安装版】

http://download.microsoft.com/do ... ngTools/dbg_x86.msi

x64位版本下载：【微软官方安装版】

http://download.microsoft.com/do ... amd64/dbg_amd64.msi

三、设置符号表：

符号表是WinDbg关键的“数据库”，如果没有它，WinDbg基本上就是个废物，无法分析出更多问题原因。所以使用WinDbg设置符号表，是必须要走的一步。

1、运行WinDbg软件，File-> Symbol File Path【Ctrl+S】弹出符号表设置窗。

2、将符号表地址：SRV*C:\Symbols*http://msdl.microsoft.com/download/symbols粘贴在输入框中，点击确定即可。

3、保存设置，点击File-> Save Workspace即可，否则每次运行windbg都要重新填写symbol search path。

四、打开一个dump：

当你拿到一个dmp文件后，可使用【Ctrl+D】快捷键来打开一个dmp文件，或者点击WinDbg界面上的【File=>Open Crash Dump...】按钮，来打开一个dmp文件

session”，然后点否即可。

第一次打开dmp文件时，可能会收到如下提示，出现这个提示时，勾选“Don't ask again in this WinDbg

当你想打开第二个dmp文件时，可能因为上一个分析记录未清除，导致无法直接分析下一个dmp文件，此时你可以使用工具栏stop debugging按钮【Shift+F5】来关闭上一个dmp分析记录。

至此，简单的WinDbg使用你已经学会了！

五、通过简单的几个步骤学会分析一些dmp文件：

第一个关键信息：System Uptime（开机时间）：

通过观察这个时间你就可以知道问题是在什么时候出现的，例如时间小于1分钟基本可以定位为开机蓝屏，反之大于一分钟则可证明是上机后或玩的过程中出现问题了。

接下来用一个简单的例子来学习简单的dmp分析，下图中System Uptime: 0 days 0:14:23.581，意思是0天(days)0小时14分23秒581毫秒时出现蓝屏了，看来是上机没多久就蓝屏了，这位顾客很悲催……

那么是什么导致蓝屏的呢？接下来我们就要注意第二个关键信息了！

第二个关键信息：Probaly caused by（造成蓝屏可能的原因）

这个信息是相对比较重要的一个信息，如果你运气好的话，通过这个信息基本上可以看到导致蓝屏的驱动或者程序名称了，就像下图一样，初步的分析已经有了结果，Probaly caused by后面显示的是一个名为KiMsgProtect.sys的驱动文件导致蓝屏，这个文件就是恒信一卡通的一个关键驱动。因此蓝屏则很有可能和一卡通有关。

括号中驱动文件名后面的+号代表的是偏移地址，假如多个dmp文件的驱动文件名一样，且偏移地址也一样，则问题原因极有可能是同一个，这个偏移地址与汇编有关，这里不多做介绍。

Kdump.sys这个蓝屏信息是指云更新的dmp捕捉机制，这并不是蓝屏原因。

其实，对于分析蓝屏dmp并不是每次运气都那么好，假如刚刚打开dmp文件未看到明确的蓝屏原因时，我们就需要借助一个命令来进一步分析dmp，这个命令就是：!analyze -v，这个命令能够自动分析绝大部分蓝屏原因。当初步分析没有结果时，可以使用该命令进一步分析故障原因，当然你也可以直接点击链接样式的!analyze -v来进行执行该命令，为了让大家更直观的看懂里面的信息，大家可以直接看图片中的注释信息。

《windbg》
由：免费论文网互联网用户整理提供,链接地址：
http://m.csmayi.cn/meiwen/22649.html
转载请保留,谢谢!