关于.NET 1.1中的c#：未处理的异常处理程序

我正在维护.NET 1.1应用程序，因此我要承担的任务之一就是确保用户不会看到任何不友好的错误通知。

我在Application.ThreadException和AppDomain.CurrentDomain.UnhandledException中添加了处理程序，但确实会调用它们。我的问题是标准CLR错误对话框仍然显示(在调用异常处理程序之前)。

Jeff在这里和这里的博客上谈论了这个问题。但是没有解决方案。那么.NET 1.1中处理未捕获的异常并显示友好对话框的标准方法是什么？

Jeff的回答被标记为正确答案，因为他提供的链接包含有关如何执行所需操作的最完整信息。

哦，在Windows窗体中，您绝对应该能够使它工作。您唯一需要注意的是事情发生在不同的线程上。

我在这里有一份旧的Code Project文章，该文章应该会有所帮助：

用户友好的异常处理

.NET 1.x Windows Forms应用程序中未处理的异常行为取决于：

• 引发异常的线程类型
• 是否在窗口消息处理期间发生
• 是否将调试器附加到进程
• DbgJitDebugLaunchSetting注册表设置
• App.Config中的jitDebugging标志
• 是否覆盖Windows Forms异常处理程序
• 是否处理CLRa？异常事件
• 月相

未处理异常的默认行为是：

• 如果在泵送窗口消息时在主线程上发生异常，则Windows窗体异常处理程序将拦截该异常。
• 如果在泵送窗口消息时在主线程上发生异常，除非Windows窗体异常处理程序将其拦截，否则它将终止应用程序进程。
• 如果异常发生在手动线程池或终结器线程上，则CLR会将其吞噬。

未处理的异常的联系点为：

• Windows窗体异常处理程序。
• JIT调试注册表开关DbgJitDebugLaunchSetting。
• CLR未处理的异常事件。

Windows窗体内置的异常处理默认情况下执行以下操作：

• 在以下情况下捕获未处理的异常：
  • 异常在主线程上，没有附加调试器。
  • 窗口消息处理期间发生异常。
  • App.Config中的jitDebugging = false。
• 向用户显示对话框并阻止应用终止。

您可以通过在App.Config中将jitDebugging = true设置为禁用后一种行为。但是请记住，这可能是您终止应用终止的最后机会。因此，捕获未处理的异常的下一步是注册事件Application.ThreadException，例如：

请注意HKEY_LOCAL_MACHINE \\\\\\\\ Software.NetFramework下的注册表设置DbgJitDebugLaunchSetting。这是我知道的三个值之一：

• 0：显示用户对话框，询问"调试或终止"。
• 1：让CLR处理异常。
• 2：启动在DbgManagedDebugger注册表项中指定的调试器。

在Visual Studio中，转到菜单工具a？’选项a？’调试a？’JIT将此键设置为0或2。但是，在最终用户的计算机上，通常最好设置为1。请注意，此注册表项在CLR未处理的异常事件发生之前起作用。

最后一个事件是您记录未处理的异常的最后机会。它是在您的Final代码块执行之前触发的。您可以按以下方式拦截此事件：

AppDomain.UnhandledException是事件，而不是全局异常处理程序。这意味着，到它被提出时，您的应用程序已经不堪重负了，除了进行清理和错误日志记录之外，您无能为力。

幕后发生的事情是：框架检测到异常，将调用堆栈移到最顶端，没有找到可以从错误中恢复的处理程序，因此无法确定继续执行是否安全。因此，出于对您的礼貌，它启动了关闭序列并触发了此事件，因此您可以对已经结束的过程表示敬意。如果在主线程中未处理异常，则会发生这种情况。

没有针对这种错误的单点解决方案。您需要在发生此错误的所有位置的上游放置一个真正的异常处理程序(捕获块)，然后将其转发到(例如)全局处理程序方法/类，该方法/类将根据以下情况确定是否可以安全地进行报告和继续操作：异常类型和/或内容。

编辑：可以禁用(= hack)Windows内置的错误报告机制，这样当您的应用程序关闭时，不会显示强制性的"崩溃和刻录"对话框。但是，这对系统中的所有应用程序都有效，而不仅仅是您自己的应用程序。

这是控制台应用程序还是Windows Forms应用程序？如果它是.NET 1.1控制台应用程序，则可悲的是，这是设计使然-由MSFT开发人员在您引用的第二篇博客文章中进行了确认：

BTW, on my 1.1 machine the example from MSDN does have the expected output; it's just that the second line doesn't show up until after you've attached a debugger (or not). In v2 we've flipped things around so that the UnhandledException event fires before the debugger attaches, which seems to be what most people expect.

听起来.NET 2.0做得更好(感谢天作之功)，但是说实话，我从来没有时间回过头来检查。

这是Windows窗体应用程序。被Application.ThreadException捕获的异常工作正常，而且我没有收到难看的.NET异常框(OK终止，Cancel调试？谁提出了该？？)。

我遇到了一些未被该异常捕获的异常，并最终导致了引起问题的AppDomain.UnhandledException事件。我想我已经捕获了大多数此类异常，并且现在正在我们的漂亮错误框中显示它们。

因此，我只希望没有其他情况会导致Application.ThreadException处理程序无法捕获异常。