Windbg 崩溃转储分析

Question

Windbg 崩溃转储分析

6

我很难从使用ProcDump创建的崩溃转储中获取任何有意义的信息，但我相信它与我经常遇到的看似随机的崩溃相关。

我在Windows 7 64位上运行VB6应用程序。每隔一段时间，它会崩溃，并在错误日志中留下一个故障ntdll.dll的条目，但没有提供更多信息。因此，我一直在运行带有SysInternals的ProcDump的进程，以自动为我创建崩溃转储文件。

我无法在公司内部重新创建崩溃，因此我相信如果我有任何转储文件，它会告诉我问题所在。然而，在运行了大部分时间后，我发现ProcDump已经写入了几个转储文件，尽管程序仍在正常运行。它似乎指向了ntdll.dll的问题，但我不知道从哪里开始修复它。

在其中一个转储文件上运行!analyze -v命令，结果如下：

*******************************************************************************
*                                                                             *
*                        Exception Analysis                                   *
*                                                                             *
*******************************************************************************


FAULTING_IP: 
+0
00000000 ??              ???

EXCEPTION_RECORD:  ffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 00000000
   ExceptionCode: 80000003 (Break instruction exception)
  ExceptionFlags: 00000000
NumberParameters: 0

FAULTING_THREAD:  000007c8

PROCESS_NAME:  application.exe

ERROR_CODE: (NTSTATUS) 0x80000003 - {EXCEPTION}  Breakpoint  A breakpoint has been reached.

EXCEPTION_CODE: (HRESULT) 0x80000003 (2147483651) - One or more arguments are invalid

NTGLOBALFLAG:  0

APPLICATION_VERIFIER_FLAGS:  0

APP:  application.exe

BUGCHECK_STR:  APPLICATION_FAULT_STATUS_BREAKPOINT_AFTER_CALL

PRIMARY_PROBLEM_CLASS:  STATUS_BREAKPOINT_AFTER_CALL

DEFAULT_BUCKET_ID:  STATUS_BREAKPOINT_AFTER_CALL

LAST_CONTROL_TRANSFER:  from 7754431f to 7752014d

STACK_TEXT:  
0382fdf4 7754431f 00000005 035e62c8 00000001 ntdll!ZwWaitForMultipleObjects+0x15
0382ff88 74cd339a 00000000 0382ffd4 77539ed2 ntdll!TppWaiterpThread+0x33d
0382ff94 77539ed2 035e6298 74e2a30c 00000000 kernel32!BaseThreadInitThunk+0xe
0382ffd4 77539ea5 775441f3 035e6298 00000000 ntdll!__RtlUserThreadStart+0x70
0382ffec 00000000 775441f3 035e6298 00000000 ntdll!_RtlUserThreadStart+0x1b


STACK_COMMAND:  ~0s; .ecxr ; kb

FOLLOWUP_IP: 
ntdll!ZwWaitForMultipleObjects+15
7752014d 83c404          add     esp,4

SYMBOL_STACK_INDEX:  0

SYMBOL_NAME:  ntdll!ZwWaitForMultipleObjects+15

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: ntdll

IMAGE_NAME:  ntdll.dll

DEBUG_FLR_IMAGE_TIMESTAMP:  4ce7ba58

FAILURE_BUCKET_ID:  STATUS_BREAKPOINT_AFTER_CALL_80000003_ntdll.dll!ZwWaitForMultipleObjects

BUCKET_ID:  APPLICATION_FAULT_STATUS_BREAKPOINT_AFTER_CALL_ntdll!ZwWaitForMultipleObjects+15

WATSON_STAGEONE_URL:  http://watson.microsoft.com/StageOne/BlackJack_exe/1_5_0_0/50227d4e/unknown/0_0_0_0/bbbbbbb4/80000003/00000000.htm?Retriage=1

Followup: MachineOwner

有谁能指导我正确的方向，帮我理解这个条目，以及我可以采取什么措施吗？（涉及IT技术）

- Geo Ego

2

你在运行procdump时调试这个应用程序吗？APPLICATION_FAULT_STATUS_BREAKPOINT_AFTER_CALL似乎表明调试器中断了进程，并且这是procdump捕获的转储。因此，这些转储不会对您有所帮助，因为它们不是实际问题的快照。ProcDump是一个非常轻量级的工具，您应该尝试在实际问题发生的地方运行它，然后尝试分析这些转储。 - jcopenha

我当时并没有进行调试。我只是在生产机器上安装了ProcDump，并编写脚本在启动时运行它（C:\apps\procdump.exe -accepteula -e -h -n 10 -t -w application.exe C:\application.dmp）。所以基本上，我正在运行ProcDump和我们编译的可执行文件一起，捕获它们出现的转储。所以你的意思是这些转储基本上是由ProcDump引起的，所以我不需要担心它们？我试图捕获的错误最终肯定会导致程序终止，所以如果它在现场发生，那就是我想要获取的转储。 - Geo Ego

我并不是说你不需要担心它们。只是!analyze -v报告让我认为这些不是真正的崩溃，而是调试器中断。我会检查各个线程的调用堆栈，看看是否还有其他异常。 - jcopenha

我在查看调用堆栈时没有发现任何其他异常，所以我希望这是好的。 - Geo Ego

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- KateButenko · Accepted Answer

为了确保，我已经在我的本地进行了一些测试，将其连接到健康的进程并对刚启动的进程进行了转储。在所有情况下，!analyze -v 的输出与您的相似，只是我的更详细。我认为这取决于调试器版本。

例如，这是我连接到刚启动的 Paint 后得到的输出：

*******************************************************************************
*                                                                             *
*                        Exception Analysis                                   *
*                                                                             *
*******************************************************************************

GetPageUrlData failed, server returned HTTP status 404
URL requested:     http://watson.microsoft.com/StageOne/mspaint_exe/6_1_7600_16385/4a5bca29/ntdll_dll/6_1_7601_17725/4ec4aa8e/80000003/00050530.htm?Retriage=1

FAULTING_IP: 
ntdll!DbgBreakPoint+0
00000000`76d90530 cc              int     3

EXCEPTION_RECORD:  ffffffffffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 0000000076d90530 (ntdll!DbgBreakPoint)
ExceptionCode: 80000003 (Break instruction exception)
ExceptionFlags: 00000000
NumberParameters: 1
Parameter[0]: 0000000000000000

FAULTING_THREAD:  0000000000000cbc

DEFAULT_BUCKET_ID:  STATUS_BREAKPOINT

PROCESS_NAME:  mspaint.exe

ERROR_CODE: (NTSTATUS) 0x80000003 - {EXCEPTION}  Breakpoint  A breakpoint has been reached.

EXCEPTION_CODE: (HRESULT) 0x80000003 (2147483651) - One or more arguments are invalid

EXCEPTION_PARAMETER1:  0000000000000000

MOD_LIST: <ANALYSIS/>

NTGLOBALFLAG:  0

APPLICATION_VERIFIER_FLAGS:  0

PRIMARY_PROBLEM_CLASS:  STATUS_BREAKPOINT

BUGCHECK_STR:  APPLICATION_FAULT_STATUS_BREAKPOINT

LAST_CONTROL_TRANSFER:  from 0000000076e37ef8 to 0000000076d90530

STACK_TEXT:  


FOLLOWUP_IP: 
ntdll!DbgBreakPoint+0
00000000`76d90530 cc              int     3

SYMBOL_STACK_INDEX:  0

SYMBOL_NAME:  ntdll!DbgBreakPoint+0

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: ntdll

IMAGE_NAME:  ntdll.dll

DEBUG_FLR_IMAGE_TIMESTAMP:  4ec4aa8e

STACK_COMMAND:  ~8s ; kb

FAILURE_BUCKET_ID:  STATUS_BREAKPOINT_80000003_ntdll.dll!DbgBreakPoint

BUCKET_ID:  X64_APPLICATION_FAULT_STATUS_BREAKPOINT_ntdll!DbgBreakPoint+0

WATSON_STAGEONE_URL:      http://watson.microsoft.com/StageOne/mspaint_exe/6_1_7600_16385/4a5bca29/ntdll_dll/6_1_7601_17725/4ec4aa8e/80000003/00050530.htm?Retriage=1

Followup: MachineOwner
---------

我也查看了这里的 ProcDump 标志说明：http://technet.microsoft.com/en-us/sysinternals/dd996900.aspx。似乎使用命令行像

C:\apps\procdump.exe -accepteula -e -h -n 10 -t -w application.exe

如果你想让procdump在出现任何挂起或异常的情况下停止，而不设置特定参数，例如内存使用量或CPU使用率百分比，我可以帮你。

我建议使用DebugDiag，它提供了一个漂亮的UI，您可以在其中配置规则，描述何时应创建转储文件。

以下是我对如何在遇到过多内存使用问题或高CPU使用率时收集转储文件的解释：

http://kate-butenko.blogspot.com/2012/06/how-to-gather-dump-with-debugdiag.html

这里还有另一篇基于截图的精美说明，介绍如何在DebugDiag中获取特定异常的转储文件：

http://blogs.msdn.com/b/kaushal/archive/2012/05/09/using-debugdiag-to-capture-a-dump-on-first-chance-exception.aspx

除DebugDiag之外，您还可以检查AdPlus工具（位于C:\Program Files\Debugging Tools for Windows (x64)文件夹中）。但我更喜欢DebugDiag，因为它可以捕获特定类型的异常。