为什么win32定时器回调中未处理的异常不会被调试器视为未处理的异常？ [英] Why are unhandled exceptions thrown in win32 timer callbacks not treated as unhandled exceptions by the debugger?

问题描述

我一直在跟踪一个真正阴险的错误在工作。似乎导致我一直在追踪的奇怪行为的事件似乎是处理定时器回调时抛出的异常。这个例外不是由我的任何代码来处理的，所以我希望调试器可以被通知未经处理的异常，并且提醒我一个不错的有趣的弹出窗口。不，相反，第一次机会异常消息跟踪到调试器，一切都静默地移动。

我已经写了以下程序来演示此问题： / p>

  #includestdafx.h
 #include< Windows.h> 
 
 class FooExcept 
 {
}; 
 
 VOID CALLBACK计时器（HWND hwnd，
 UINT uMsg，
 UINT_PTR idEvent，
 DWORD dwTime）
 {
 printf（Here\\ \
）; 
 throw FooExcept（）; 
 printf（Also Here\\\
）; 
} 
 
 
 int _tmain（int argc，_TCHAR * argv []）
 {
 SetTimer（0，0，1000，Timer）; 
 
 int bRet; 
 HWND hWnd; 
 MSG msg; 
 //标准Win32消息泵
 while（（bRet = GetMessage（& msg，NULL，0，0））！= 0）
 {
 if（bRet == -1）
 {
 //处理错误并可能退出
} 
 else 
 {
 TranslateMessage（& msg）; 
 DispatchMessage（& msg）; 
} 
} 
 
 return 0; 
} 
  

此程序的输出到Visual Studio输出窗口是这样重复的： / p>

 
 TimerTest.exe中的0x76dbb9bc的第一次异常：Microsoft C ++异常：FooExcept在内存位置0x0034f743 .. 
 

当然，我的项目更复杂，正在向调试器打印出大量的TRACE信息。

HOWEVER

这不是我的关注。这显然是一个例外，我没有处理。 Windows是否暗中决定为我处理这个问题？为什么？如果不是，为什么不给我一个公然的弹出窗口提醒我未处理的例外？这样的弹出窗口可以节省我几天的调试时间。

这个行为在XP / VS 2008和Win7 / VS 2010之间似乎是一致的。

解决方案

在某些程度上（见下文）Windows 7 SP1中已修复。

在文章 http://support.microsoft.com/kb/976038 中，您会发现提到的bugfix和解释如何使用它来禁用此行为。您必须：

• 在注册表中设置流程选项或


• 调用函数 SetProcessUserModeExceptionPolicy 导出的 kernel32.dll

我已通过 Win7和WS08R2 SP1中的更新进行了验证。 xls 认为此修补程序确实包含在Windows 7 Service Pack 1中，因此您只需启用该功能即可（假设您足够幸运已安装Windows 7 SP1）。

至于解释为什么这已经完成了，我们可以猜测一些不明智的尝试，以防止遗留应用程序以后向兼容性的名义崩溃。

I've been tracking down a really insidious bug at work. The event that seems to cause the very strange behavior I've been tracking down appears to be an exception being thrown while processing a timer callback. The exception is NOT handled by any of my code, therefore I would expect the debugger to be notified of the unhandled exception and alert me with a nice obnoxous pop-up. No, instead the "first chance" exception message traces out to the debugger and everything silently moves on.

I've written up the following program that demonstrates this issue:

#include "stdafx.h"
#include <Windows.h>

class FooExcept
{
};

VOID CALLBACK Timer(HWND hwnd,
    UINT uMsg,
    UINT_PTR idEvent,
    DWORD dwTime)
{
    printf("Here\n");
    throw FooExcept();
    printf("Also Here\n");
}


int _tmain(int argc, _TCHAR* argv[])
{
    SetTimer(0, 0, 1000, Timer);

    int bRet;
    HWND hWnd;
    MSG msg;
    // Standard Win32 message pump
    while( (bRet = GetMessage( &msg, NULL, 0, 0 )) != 0)
    { 
        if (bRet == -1)
        {
            // handle the error and possibly exit
        }
        else
        {
            TranslateMessage(&msg); 
            DispatchMessage(&msg); 
        }
    }

    return 0;
}

The output of this program to the Visual Studio Output window is this repeated:

First-chance exception at 0x76dbb9bc in TimerTest.exe: Microsoft C++ exception: FooExcept at memory location 0x0034f743..

Of course my project is MUCH more complicated and is printing out a lot of TRACE information to the debugger. Its easy for first-chance exception to get lost in the output.

HOWEVER

That's not my concern. This is clearly an exception Im not handling. Is Windows surreptitiously deciding to handle this for me? Why? If not, why isn't it giving me a blatant pop-up alerting me of the unhandled exception? Such a pop-up could have saved me days of debugging.

This behavior seems consistent between XP/VS 2008 and Win7/VS 2010.

解决方案

This has been been fixed, to some degree (see below), in Windows 7 SP1.

In article http://support.microsoft.com/kb/976038 you will find mention of a bugfix and explanation how to use it to disable this behaviour. You have to either:

• set process options in the registry or
• call function SetProcessUserModeExceptionPolicy exported by kernel32.dll

I have verified in Updates in Win7 and WS08R2 SP1.xls that this bugfix is indeed included in Windows 7 Service Pack 1, so all you have to do is to enable it (assuming you are lucky enough to have Windows 7 SP1 already installed).

As for explanation why this has been done, well we can just guess some ill-advised attempt to prevent legacy application from crashing in the name of backwards compatibility.

这篇关于为什么win32定时器回调中未处理的异常不会被调试器视为未处理的异常？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！