如果堆栈跨越内核边界，为什么 64 位 Windows 不能在异常期间展开堆栈 - 而 32 位 Windows 可以？

整个问题的上下文来自:

The case of the disappearing OnLoad exception – user-mode callback exceptions in x64

背景

在 32 位 Windows 中，如果我在我的用户模式代码中抛出一个异常，它是从内核模式代码中回调的，它是从我的中调用的>用户模式代码，例如:

User mode                     Kernel Mode
------------------            -------------------
CreateWindow(...);   ------>  NtCreateWindow(...)
                                   |
WindowProc   <---------------------+                                   

Windows 中的结构化异常处理 (SEH) 可以展开堆栈，通过内核模式展开，回到我的用户代码，我可以在其中处理异常并看到有效的堆栈跟踪。

但不是在 64 位 Windows 中

64 位版本的 Windows 无法执行此操作:

For complicated reasons, we cannot propagate the exception back on 64-bit operating systems (amd64 and IA64). This has been the case ever since the first 64-bit release of Server 2003. On x86, this isn’t the case – the exception gets propagated through the kernel boundary and would end up walking the frames back

并且由于在这种情况下无法返回可靠的堆栈跟踪，因此必须做出决定:让您看到非无意义的异常，或者完全隐藏它:

The kernel architects at the time decided to take the conservative AppCompat-friendly approach – hide the exception, and hope for the best.

文章接着讨论了所有 64 位 Windows 操作系统的行为方式:

• Windows XP 64 位
• Windows Server 2003 64 位
• Windows Vista 64 位
• Windows Server 2008 64 位

但是从 Windows 7(和 Windows Server 2008)开始，架构师改变了他们的想法 - 有点。对于仅 64 位应用程序(不是 32 位应用程序)，它们将(默认情况下)停止抑制这些用户-内核-用户异常.因此，默认情况下，打开:

• Windows 7 64 位
• Windows 服务器 2008

所有 64 位应用程序都将看到这些异常，而它们以前从未看到过。

In Windows 7, when a native x64 application crashes in this fashion, the Program Compatibility Assistant is notified. If the application doesn’t have a Windows 7 Manifest, we show a dialog telling you that PCA has applied an Application Compatibility shim. What does this mean? This means, that the next time you run your application, Windows will emulate the Server 2003 behavior and make the exception disappear. Keep in mind, that PCA doesn’t exist on Server 2008 R2, so this advice doesn’t apply.

所以问题

问题是为什么 64 位 Windows 无法通过内核转换展开堆栈，而 32 位版本的 Windows 可以？

唯一的提示是:

For complicated reasons, we cannot propagate the exception back on 64-bit operating systems (amd64 and IA64).

提示是它很复杂。

我可能不明白解释，因为我不是操作系统开发人员 - 但我想知道为什么。

更新:停止抑制 32 位应用程序的修补程序

Microsoft 已发布 a hotfix enables 32-bit applications也不再抑制异常:

KB976038: Exceptions that are thrown from an application that runs in a 64-bit version of Windows are ignored

• An exception that is thrown in a callback routine runs in the user mode.

In this scenario, this exception does not cause the application to crash. Instead, the application enters into an inconsistent state. Then, the application throws a different exception and crashes.

A user mode callback function is typically an application-defined function that is called by a kernel mode component. Examples of user mode callback functions are Windows procedures and hook procedures. These functions are called by Windows to process Windows messages or to process Windows hook events.

此修补程序随后可让您阻止 Windows 在全局范围内处理异常:

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options
DisableUserModeCallbackFilter: DWORD = 1

或每个应用程序:

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\Notepad.exe
DisableUserModeCallbackFilter: DWORD = 1

KB973460 中还记录了 XP 和 Server 2003 上的行为:

• Exceptions that are thrown from a 64-bit application that is running in the 64-bit editions of Windows Server 2003 or of Windows XP Professional are silently ignored

一个提示

我在调查使用 xperf 在 64 位 Windows 上捕获堆栈跟踪时发现了另一个提示:

Stack Walking in Xperf

Disable Paging Executive

In order for tracing to work on 64-bit Windows you need to set the DisablePagingExecutive registry key. This tells the operating system not to page kernel mode drivers and system code to disk, which is a prerequisite for getting 64-bit call stacks using xperf, because 64-bit stack walking depends on metadata in the executable images, and in some situations the xperf stack walk code is not allowed to touch paged out pages. Running the following command from an elevated command prompt will set this registry key for you.

 REG ADD "HKLM\System\CurrentControlSet\Control\Session Manager\Memory Management" -v 
 DisablePagingExecutive -d 0x1 -t REG_DWORD -f

After setting this registry key you will need to reboot your system before you can record call stacks. Having this flag set means that the Windows kernel locks more pages into RAM, so this will probably consume about 10 MB of additional physical memory.

这给人的印象是在 64 位 Windows 中(并且仅在 64 位 Windows 中)，不允许遍历内核堆栈，因为磁盘上可能有页面。

最佳答案

我是很久以前编写此修补程序以及博客文章的开发人员。主要原因是出于性能原因，当您转换到内核空间时，并不总是捕获完整的寄存器文件。

如果您进行正常的系统调用，x64 Application Binary Interface (ABI) 只需要你保留 the non-volatile registers (类似于进行正常的函数调用)。但是，正确展开异常需要您拥有所有 寄存器，因此这是不可能的。基本上，这是在关键场景(即每秒可能发生数千次的场景)的性能与 100% 正确处理病态场景(崩溃)之间的选择。

红利阅读

• Overview of x64 Calling Conventions
• x86 Software Conventions - Register Usage

关于windows - 为什么 64 位 Windows 不能取消用户-内核-用户异常？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/11376795/