注意：我对禁用WER不感兴趣,我对WER未启动的崩溃场景感兴趣,尽管它应该和Windows“默默地”终止应用程序.

在Windows XP上,编写一个C或C应用程序(在用户模式下)是非常简单的,它会以这样的方式混淆自己的地址空间：当最终引发访问冲突(或其他未处理的Win32异常)时,Windows XP将只是默默地终止进程而不通知用户：

...
void stackbreaker() {
    printf("%s\n",__FUNCTION__);
    // global/static buffer
    static char buf[128] = "In a hole in the ground there lived a hobbit. And it burrowed through your stack. It even built a round door into you function.";
    // Get address on the stack
    char local;
    char* stack = &local;
    // nuke the stack:
    memcpy(stack - 64,buf,sizeof(buf));
    // Kaboom. No user defined unhandled exception filter will be called. Stack nuked.
    // Process will terminate silently on Windows XP.
    // But on Windows-7 you still get the WER dialog.
}
...

在一个简单的C项目中调用上述函数(在发布模式下 – 在测试时注意那些编译器优化 – 而不是在调试器下运行)将：

>在XP下静默终止进程.
>在Windows-7下显示WER崩溃对话框.
>旁白：在任何情况下都不会调用您自己的未处理异常过滤器,即使您通过SetUnhandledExceptionFilter设置了一个

我现在想知道的是 – 在Windows 7下 – 是否已经实现了WER机制,我总是在我的应用程序中获得崩溃[a]的错误对话框,或者即使在Windows 7中是否存在进程损坏情况,这会阻止WER对话框弹出？

我会添加一些读数：

在Windows via C/C++ (5th ed by Richter,Nasarre)书中,他们描述了“错误过程”中发生的事情(第711页)：

1. Exception filters.
2. …
3. …
4. kernel detects unhandled exception
5. blocking ALPC call to Wer Service
6. WER reporting kicks in.
7. …

现在,他们指出Win7与Windows XP的不同之处(引用本书第710页:)

… Starting with Windows Vista,the UnhandledExceptionFilter function no longer sends an error report to MS’ servers. Instead. The kernel detects that the exception is not handled by the user-mode thread (Step 4)…

因此,这意味着,在Vista及以上版本中,“崩溃”的过程完全没有任何办法可以阻止WER进入.我试图确认或反驳这一点.

[a]：显然,通过调用各种* exit或terminate *函数之一,可以很容易地“杀死”一个进程而没有任何痕迹.问题是,如果你可以排除这样的终止原因,(怎么样)可能会以一种阻止WER对话框显示的方式在Win7上“崩溃”用户模式进程.