windbg分析异常崩溃(翻译自自带帮助)

帮助原文(英文):http://www.dbgtech.net/windbghelp/index.html
Windows的调试工具
使用!"analyze "扩展命令
调试一个崩溃的目标计算机或应用程序的第一步是使用 !analyze 扩展命令。

这个扩展可以执行大量的自动分析。这个分析的结果显示在调试器命令窗口中。

你应该使用-v选项,以获得完全节制的数据显示。关于其他选项的详情,请参见!!分析参考页。

本主题包含。

一个用户模式的 !analyze -v 示例

内核模式的 !analyze -v 示例

跟进字段和triage.ini文件

其他的!分析技术

一个用户模式的 !analyze -v 例子
在这个例子中,调试器被连接到一个遇到异常的用户模式应用程序上。

0:000> !analyze -v


  • 异常分析 *

调试器SolutionDb Connection::Open failed 80004005

如果您连接到互联网,调试器试图访问由微软维护的崩溃解决方案数据库。在这种情况下,显示了一条错误信息,表明你的机器无法访问互联网,或者网站无法工作。

FAULTING_IP。
ntdll! PropertyLengthAsVariant+73
77f97704 cc int 3

FAULTING_IP字段显示故障发生时的指令指针。

EXCEPTION_RECORD: ffffffff -- (.exr ffffffffffffff)
ExceptionAddress: 77f97704 (ntdll!PropertyLengthAsVariant+0x00000073)
异常代码。80000003 (中断指令异常)
异常标志。00000000
NumberParameters: 3
参数[0]: 00000000
Parameter[1]: 00010101
参数[2]: ffffffff

EXCEPTION_RECORD字段显示了这次崩溃的异常记录。这个信息也可以通过使用.exr(显示异常记录)命令来查看。

BUGCHECK_STR: 80000003

BUGCHECK_STR字段显示了异常代码。这个名字是个错误的说法--BUGCHECK这个词实际上表示的是内核模式的崩溃。在用户模式的调试中,异常代码将被显示--在这个例子中,是0x80000003。

default_bucket_id: application_fault

DEFAULT_BUCKET_ID字段显示了这个故障所属的一般故障类别。

PROCESS_NAME: MyApp.exe

PROCESS_NAME字段指定了引发异常的进程的名称。

LAST_CONTROL_TRANSFER:从01050963到77f97704

LAST_CONTROL_TRANSFER字段显示了堆栈中的最后一次调用。在这个例子中,地址为0x01050963的代码在0x77F97704处调用了一个函数。你可以用ln(List Nearest Symbols)命令使用这些地址来确定这些地址所在的模块和函数。

STACK_TEXT:
0006b9dc 01050963 00000000 0006ba04 000603fd ntdll! PropertyLengthAsVariant+0x73
0006b9f0 010509af 00000002 0006ba04 77e1a449 MyApp!FatalErrorBox+0x55 [D:\source_files\MyApp\util.c @ 541]
0006da04 01029f4e 01069850 0000034f 01069828 MyApp!ShowAssert+0x47 [D:\source_files\MyApp\util.c @ 579] 。
0006db6c 010590c3 000e01ea 0006fee4 0006feec MyApp!SelectColor+0x103 [D:\source_files\MyApp\colors.c @ 849] 。
0006fe04 77e11d0a 000e01ea 00000111 0000413c MyApp!MainWndProc+0x1322 [D:\source_files\MyApp\MyApp.c @ 1031] 。
0006fe24 77e11bc8 01057da1 000e01ea 00000111 USER32!UserCallWinProc+0x18
0006feb0 77e172b4 0006fee4 00000001 010518bf USER32!DispatchMessageWorker+0x2d0
0006febc 010518bf 0006fee4 00000000 01057c5d USER32!DispatchMessageA+0xb
0006fec8 01057c5d 0006fee4 77f82b95 77f83920 MyApp!ProcessQCQPMessage+0x3b [D:\source_files\MyApp\util.c @ 2212] 。
0006ff70 01062cbf 00000001 00683ed8 00682b88 MyApp!main+0x1e6 [D:\source_files\MyApp\MyApp.c @ 263]
0006ffc0 77e9ca90 77f82b95 77f83920 7ffdf000 MyApp!mainCRTStartup+0xff [D:\source_files\MyApp\crtexe.c @ 338)
0006fff0 00000000 01062bc0 00000000 000000c8 KERNEL32!BaseProcessStart+0x3d

STACK_TEXT字段显示了出错组件的堆栈跟踪。

FOLLOWUP_IP。
MyApp!FatalErrorBox+55
01050963 5e pop esi

FOLLOWUP_NAME: dbg

SYMBOL_NAME。 MyApp!FatalErrorBox+55

MODULE_NAME: モンクレール_NAME: MyApp

IMAGE_NAME。 MyApp.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 383490a9

当 !analyze 确定了可能导致错误的指令时,它将在 FOLLOWUP_IP 字段中显示。SYMBOL_NAME、MODULE_NAME、IMAGE_NAME和DBG_FLR_IMAGE_TIMESTAMP字段显示与该指令对应的符号、模块、图像名称和图像时间戳。

STACK_COMMAND: .ecxr ; kb

STACK_COMMAND字段显示用于获得STACK_TEXT的命令。你可以用这个命令来重复这个堆栈跟踪显示,或者改变它来获得相关的堆栈信息。

BUCKET_ID: 80000003_MyApp!FatalErrorBox+55

BUCKET_ID: 80000003_MyApp!FatalErrorBox+55

BUCKET_ID字段显示了当前故障所属的具体故障类别。这个类别有助于调试器确定在分析输出中显示哪些其他信息。

跟进: dbg

关于FOLLOWUP_NAME和Followup字段的信息,见The Followup Field and the triage.ini File。

还有其他各种可能出现的字段。

如果控制被转移到一个无效的地址,那么FAULTING_IP字段将包含这个无效的地址。FAILED_INSTRUCTION_ADDRESS字段代替了FOLLOWUP_IP字段,将显示从这个地址反汇编的代码,尽管这个反汇编可能毫无意义。在这种情况下,SYMBOL_NAME、MODULE_NAME、IMAGE_NAME和DBG_FLR_IMAGE_TIMESTAMP字段将指这个指令的调用者。
如果处理器发生错误,你可能会看到SINGLE_BIT_ERROR、TWO_BIT_ERROR或POSSIBLE_INVALID_CONTROL_TRANSFER字段。
如果内存损坏似乎已经发生,CHKIMG_EXTENSION字段将指定应该用来调查的!!Chkimg扩展命令。
内核模式的 !analyze -v 示例
在这个例子中,调试器被连接到一台刚刚崩溃的计算机上。

kd> !analyze -v


  • 错误检查分析 *

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
试图访问一个可分页的(或完全无效的)地址。
中断请求级别(IRQL)太高。 这通常是
这通常是由于驱动程序使用了不适当的地址造成的。
如果内核调试器可用,可以得到堆栈回溯。

显示的第一个元素显示了错误检查代码和关于这种类型的错误检查的信息。一些显示的文字可能不适用于这个特定的实例。关于每个错误检查的更多细节,见错误检查代码参考部分。

参数。
Arg1: 00000004, 被引用的内存
Arg2: 00000002,IRQL
Arg3: 00000001,数值0=读操作,1=写操作
Arg4: f832035c, 引用内存的地址

接下来显示错误检查参数。它们后面都有一个描述。例如,第三个参数是1,后面的注释解释说,这表示一个写操作失败。

调试细节。

WRITE_ADDRESS: 00000004 Nonpaged pool

current_irql: 2

接下来的几个字段根据崩溃的性质不同而不同。在这种情况下,我们看到WRITE_ADDRESS和CURRENT_IRQL字段。这些只是重述了错误检查参数中显示的信息。通过比较语句 "Nonpaged pool "和错误检查文本 "an attempt was made to access a pagable (or completely invalid) address",我们可以看到该地址是无效的。本例中的无效地址是0x00000004。

FAULTING_IP:
USBPORT!USBPORT_BadRequestFlush+7c
f832035c 894204 mov [edx+0x4],eax

FAULTING_IP字段显示故障发生时的指令指针。

default_bucket_id: driver_fault

DEFAULT_BUCKET_ID字段显示了这个故障所属的一般故障类别。

BUGCHECK_STR:0xD1

BUGCHECK_STR字段显示错误检查代码,我们已经看到了。在某些情况下会附加额外的分流信息。

TRAP_FRAME: f8950dfc -- (.trap fffffffff8950dfc)
.trap fffffffff8950dfc
ErrCode = 00000002
eax=81cc86dc ebx=81cc80e0 ecx=81e55688 edx=00000000 esi=81cc8028 edi=8052cf3c
eip=f832035c esp=f8950e70 ebp=f8950e90 iopl=0 nv up ei pl nz ac po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010216
USBPORT!USBPORT_BadRequestFlush+7c:
f832035c 894204 mov [edx+0x4],eax ds:0023:000004????????
.陷阱
重置默认上下文

TRAP_FRAME字段显示这次崩溃的陷阱帧。这个信息也可以通过使用.trap(显示陷阱帧)命令来查看。

LAST_CONTROL_TRANSFER:从f83206e0到f832035c

LAST_CONTROL_TRANSFER字段显示堆栈上的最后一次调用。在这个例子中,地址为0xF83206E0的代码调用了0xF832035C的函数。你可以使用ln(List Nearest Symbols)命令来确定这些地址所在的模块和函数。

STACK_TEXT:
f8950e90 f83206e0 024c7262 00000000 f8950edc USBPORT!USBPORT_BadRequestFlush+0x7c
f8950eb0 804f5561 81cc8644 81cc8028 6d9a2f30 USBPORT!USBPORT_DM_TimerDpc+0x10c
f8950fb4 804f5644 6e4be98e 00000000 ffdff000 nt!KiTimerListExpire+0xf3
f8950fe0 8052c47c 8053cf20 00000000 00002e42 nt!KiTimerExpiration+0xb0
f8950ff4 8052c16a efdefd44 00000000 00000000 nt!KiRetireDpcList+0x31

STACK_TEXT字段显示了故障组件的堆栈跟踪。
FOLLOWUP_IP。
USBPORT!USBPORT_BadRequestFlush+7c
f832035c 894204 mov [edx+0x4],eax

FOLLOWUP_IP字段显示了可能导致错误的指令的反汇编。

FOLLOWUP_NAME: usbtri

SYMBOL_NAME: USBPORT!USBPORT_BadRequestFlush+7c

MODULE_NAME: USBPORT

IMAGE_NAME: USBPORT.SYS

DEBUG_FLR_IMAGE_TIMESTAMP: 3b7d868b

SYMBOL_NAME、MODULE_NAME、IMAGE_NAME和DBG_FLR_IMAGE_TIMESTAMP字段显示了与此指令(如果有效)或与此指令的调用者(如果无效)相对应的符号、模块、图像和图像时间戳。

STACK_COMMAND: .trap fffffffff8950dfc ; kb

STACK_COMMAND字段显示了用于获得STACK_TEXT的命令。你可以用这个命令来重复这个堆栈跟踪显示,或者改变它来获得相关的堆栈信息。

BUCKET_ID: 0xD1_W_USBPORT!USBPORT_BadRequestFlush+7c

BUCKET_ID字段显示了当前故障所属的具体故障类别。这个类别有助于调试器确定在分析输出中显示哪些其他信息。

internal_solution_text: http://oca.microsoft.com/resredir.asp?sid=62&State=1

如果您连接到互联网,调试器会尝试访问由微软维护的崩溃解决方案数据库。这个数据库包含了大量的网页链接,这些网页都有关于已知错误的信息。如果发现与你的问题相匹配,INTERNAL_SOLUTION_TEXT字段将显示一个你可以访问的URL,以获取更多信息。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章