为了确保没有其他的事情，我在Visual Studio中创建了一个新的C Win32应用程序，并添加了：
case WM_CLOSE:
(*(int*)NULL) = 0;
break;
同样的事情：没有崩溃，只是调试日志中的第一次机会异常。如果我将相同的代码添加到WM_COMMAND处理程序，则会按预期的方式崩溃。
所以我很好奇：Windows认为其抛出的异常应该被吞噬的WM_CLOSE有什么特别之处？
(BTW：这是在Windows 7 x64，运行x86程序)
另请参阅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。
