winapi – 为什么Windows在WM_CLOSE期间吞掉异常

在试图找出为什么我正在处理的应用程序不会关闭时，我意识到它在WM_CLOSE处理程序中抛出异常。但是，除了应用程序崩溃(因为应该)，异常被默认忽略。

为了确保没有其他的事情，我在Visual Studio中创建了一个新的C Win32应用程序，并添加了：

case WM_CLOSE:
    (*(int*)NULL) = 0;
    break;

同样的事情：没有崩溃，只是调试日志中的第一次机会异常。如果我将相同的代码添加到WM_COMMAND处理程序，则会按预期的方式崩溃。

所以我很好奇：Windows认为其抛出的异常应该被吞噬的WM_CLOSE有什么特别之处？

(BTW：这是在Windows 7 x64，运行x86程序)

这个例外是WinPix上的WindowProc吞噬是预期的行为。 ( See docs.)

另请参阅Paul Betts’博客更好的解释，尤其是他的笔记

How come this doesn’t happen all the time?

Here’s why this seems to happen only on certain window messages –
remember that window messages can originate from different sources,
anyone(*) can queue a message to a window. However,certain window
messages are directly sent via win32k.sys (the most notable one being
WM_CREATE) as a direct synchronous result of a user-mode call.

似乎对这个问题有所了解。

Random ASCII also对所有这种内核模式 – 吞咽行为有一些很好的解释：

Failure to stop at all

An equally disturbing problem was introduced some years ago with
64-bit Windows and it causes some crashes to be silently ignored.

Structured exception … relies on being able to unwind the stack
(without or without calling destructors) in order to transfer
execution from where an exception occurs to a catch/__except block.

The introduction of 64-bit Windows complicated this. On 64-bit Windows
it is impossible to unwind the stack across the kernel boundary. That is,if … an exception is thrown in the callback that is
supposed to be handled on the other side of the kernel boundary,then
Windows cannot handle this.

This may seem a bit esoteric and unlikely – writing kernel callbacks
seems like a rare activity – but it’s actually quite common. In
particular,a WindowProc is a callback,and it is often called by
the kernel,…

并作为奖金：见here on SO on the why。