windows - 如何知道 80000003 断点后面是否隐藏了不同的异常(WER 对话框)

Question

我的应用程序(一个可执行文件)在远程机器上崩溃了。我无权访问该机器，因此我请求了一个通过任务管理器生成的转储。使用 WinDbg，在执行命令 !analyze -v 时，我可以在许多其他内容中看到以下文本

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

我怎么知道它是否是导致崩溃的原因？如果不是，我如何确定真正的原因？

Answer 1

INT3 断点是根本原因吗？

TLDR:如果 !findstack kernel32!WerpReportFault 产生结果，那么它可能不是根本原因。

长版:

当您的应用程序因未处理的异常而崩溃时，操作系统将使用称为 Windows 错误报告的功能来识别它。这导致了一些技术问题:

1. ntdll 中的异常调度程序启动了一个新线程。
2. 在新线程中，触发断点
3. 异常调度器也调用未处理的异常处理器
4. 如果您的应用程序没有这样的处理程序，它会将处理转发给显示对话框的 Windows 错误报告(在 kernel32 中)

如果您当时进行故障转储，您将看到以下内容:

1. 问题中提到的断点异常

   0:002> .exr -1
   ExceptionAddress: 775f000c (ntdll!DbgBreakPoint)
      ExceptionCode: 80000003 (Break instruction exception)
     ExceptionFlags: 00000000
   NumberParameters: 1
      Parameter[0]: 00000000
   

2. 内部只有一个断点的线程

   0:002> k
   ChildEBP RetAddr  
   02e2ff58 7767f926 ntdll!DbgBreakPoint
   02e2ff88 75b3338a ntdll!DbgUiRemoteBreakin+0x3c
   02e2ff94 77619f72 kernel32!BaseThreadInitThunk+0xe
   02e2ffd4 77619f45 ntdll!__RtlUserThreadStart+0x70
   02e2ffec 00000000 ntdll!_RtlUserThreadStart+0x1b
   

3. 包含前面提到的相关操作的调用堆栈

   0:001> k
   ChildEBP RetAddr  
   01aff904 770715f7 ntdll!NtWaitForMultipleObjects+0x15
   01aff9a0 75b319f8 KERNELBASE!WaitForMultipleObjectsEx+0x100
   01aff9e8 75b34200    kernel32!WaitForMultipleObjectsExImplementation+0xe0
   01affa04 75b580a4 kernel32!WaitForMultipleObjects+0x18
   01affa70 75b57f63 kernel32!WerpReportFaultInternal+0x186
   01affa84 75b57858 kernel32!WerpReportFault+0x70
   01affa94 75b577d7 kernel32!BasepReportFault+0x20
   01affb20 776574ff kernel32!UnhandledExceptionFilter+0x1af
   01affb28 776573dc ntdll!__RtlUserThreadStart+0x62
   01affb3c 77657281 ntdll!_EH4_CallFilterFunc+0x12
   01affb64 7763b499 ntdll!_except_handler4+0x8e
   01affb88 7763b46b ntdll!ExecuteHandler2+0x26
   01affbac 7763b40e ntdll!ExecuteHandler+0x24
   01affc38 775f0133 ntdll!RtlDispatchException+0x127
   01affc38 6f8c20ce ntdll!KiUserExceptionDispatcher+0xf
   

要识别 WER 断点，您可以检查这三个条件。对于后者，您可以使用 !findstack 命令，因为它可能发生在任何线程上。

0:001> !findstack kernel32!WerpReportFault
Thread 001, 2 frame(s) match
        * 04 01affa70 75b57f63 kernel32!WerpReportFaultInternal+0x186
        * 05 01affa84 75b57858 kernel32!WerpReportFault+0x70

希望方法名不要改

如何找出根本原因？

由于堆栈的创建方式，这适用于 x86(32 位)。它在 x64(64 位)上运行不佳，因为 kb 命令不可靠。在 x64 上，参数通过寄存器而不是堆栈传递，但 kb 命令仅适用于堆栈。

也就是说，异常指针作为第二个参数传递给 WerpReportFault()。您可以使用该异常指针创建一个新的转储，并将该异常作为主要异常，如下所示:

.dump /ma /xp <exception pointer> c:\path\to\newdump.dmp

接下来，关闭源转储，打开新的转储并再次分析它，例如以以下 4 个命令为起点:

.symfix
.reload
.exr -1
!analyze -v