什么控制 WinForms 中默认的 UnhandledException 策略？
我目前正在维护一个 WinForms 应用程序，该应用程序侦听 Application.ThreadException 事件捕获 GUI 线程上未处理的异常。
现在事情一直按预期进行，直到最近。但最近，这个事件不再在一些生产盒子上适当引发；当 GUI 线程上存在未处理的异常时，应用程序会跳过处理程序并崩溃。奇怪的是，我能够在我的（新）开发盒上重现这一点，但在某些机器上实际上可以正确引发该事件。
我可以通过像这样显式设置策略来使行为保持一致：
Application.SetUnhandledExceptionMode(UnhandledExceptionMode.CatchException);
但我很想知道是什么控制默认策略。 MSDN 含糊地提到了“应用程序配置文件”，但在我们的 app.config 或据我所知的任何其他配置文件中没有这样的策略设置。
是什么导致了这种不一致的行为？
I am currently maintaining a WinForms application that listens to the Application.ThreadException event to trap unhandled exceptions on GUI threads.
Now things have been working as expected until recently. But lately, this event is no longer being raised appropriately on some production boxes; the app skips the handler and just crashes when there is an unhandled exception on a GUI thread. Strangely, I am able to reproduce this on my (new) dev box, but there are some machines on which the event is in fact being raised correctly.
I am able to make the behaviour consistent by explicitly setting the policy like this:
Application.SetUnhandledExceptionMode(UnhandledExceptionMode.CatchException);
But I am curious to know what controls the default policy. MSDN makes vague allusions to an "application configuration file", but there is no such policy-setting in our app.config or any other configuration file that I know of.
What is causing this inconsistent behaviour?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我能想到的只有一个。异常处理逻辑知道是否附加了调试器。当默认的 UnhandledExceptionMode.Automatic 生效时，这一点很重要。当附加调试器时，Winforms 消息循环不会尝试捕获异常。这相当重要，它会使调试异常变得相当困难。仅当异常未处理时，调试器才会介入并显示异常助手。
使用 UnhandledExceptionMode.CatchException 是可以的，它使异常处理保持一致。换句话说，它在您的开发计算机上的行为与在客户端计算机上的行为完全相同。但您现在需要“调试”+“异常”、“抛出框”来排除代码故障。当抛出异常时，无论是否捕获异常，调试器都会停止。
There's only one that I can think of. The exception handling logic is aware whether or not a debugger is attached. That matters when the default UnhandledExceptionMode.Automatic is in effect. When a debugger is attached, the Winforms message loop does not try to catch exceptions. Which is fairly important, it would make debugging exceptions rather difficult. The debugger only steps in and displays the Exception Assistant when an exception is unhandled.
Using UnhandledExceptionMode.CatchException is okay, it makes exception handling consistent. In other words, it will behave on your dev machine exactly the same as it does on your client's machine. But you'll now need Debug + Exceptions, Thrown box to troubleshoot the code. That always makes the debugger stop when the exception is thrown, regardless of whether it is caught or not.
我也开始经历这一点。我们试图调试测试人员看到的但无法在我们自己的机器上重现的异常。我在 VS 和 viola 中打开了异常停止行为，异常确实发生了。但是，如果我按 F11 继续，我会看到异常只是被默默地忽略。
我有两台机器。一台机器是Win 7 64位，安装了VS 2008和VS 2010，因此安装了.Net 4.0。我们正在测试的应用程序是.Net 3.5，并在VS 2008中调试。
另一台机器是Win XP 32位，纯简VS 2008和.Net 3.5。
Win 7机器默默地忽略。 XP机器大声抱怨。我认为安装 .Net 4.0 改变了一些默认策略。
我已经通过打电话解决了这个问题
I've also begun to experience this. We were trying to debug exceptions that our testers were seeing and couldn't reproduce on our own machines. I turned on the stop-on-exceptions behavior in VS and viola, the exceptions were actually happening. However, if I were to F11 to continue, I'd see that the exceptions are just silently ignored.
I have two machines. One machine is Win 7 64 bit, has VS 2008 and VS 2010 installed, and so .Net 4.0 is installed. The application we're testing is .Net 3.5 and debugged in VS 2008.
The other machine is Win XP 32 bit, plain jane VS 2008 and .Net 3.5.
The Win 7 machine silently ignores. The XP machine loudly complains. I think having .Net 4.0 installed changed some default policy.
I've worked around it by calling