问题标签 [unobserved-exception]

我们最近检查了我们的错误日志，看到了很多“操作被取消”的异常。我们无法重现它们，看起来像是一个中止的请求，但它们都来自 OWIN HostAuthenticationFilter。

这是堆栈跟踪：

有没有人见过这个错误？

我试图了解 .NET 4.0 中的 UnobservedTaskException 问题，所以我编写了以下代码

UnobservedTaskException 被触发，然后我的应用程序继续工作。但是根据MSDN，该进程应该被杀死。谁能告诉我为什么？

具体来说，我将 WPF 与 MVVM 一起使用。我有一个 MainWindow，它是一个 WPF 窗口，所有操作都在其中发生。它为其属性、命令等使用相应的视图模型类。

我在 Application.xaml.vb StartUp 中设置了主 UI 线程和非 UI 线程异常处理程序，如下所示：

这部分有效

当我尝试通过故意抛出异常来测试它时，它可以工作。它实际上是在处理 Select All 按钮单击的 Sub 中的 View Model 中。

按钮：

我抛出成功捕获的异常的命令：

这部分不起作用

在同一个 MainWindow 中还有另一个按钮，类似地绑定到一个命令。但是，它使用一个任务在后台执行它的工作，并且在那里抛出的异常不会被我的包罗万象的处理程序捕获。

有几个类似的问题，但我无法真正从他们那里找出答案。在大多数情况下，AppDomain UnhandledException 似乎是答案，但它不适合我。我到底需要添加什么才能以这种方式捕获可能在非 UI 线程中抛出的异常？

我最终做了什么

当我在 Application.xaml.vb 中处理它时，我无法让 TaskScheduler.UnobservedTaskException 事件调用我的事件处理程序。但是我从另一个答案中得到了提示，我将其标记为答案，因为它最终有所帮助。

但是，它不在应用程序级别，所以如果这是一个更大的应用程序，我必须在我使用任务的每个实例中复制它。这不是我真正想要的，但现在不愿意花更多时间在上面。

我最终在 Task 中放置了一个 try-catch。在捕获中，我能够使用 Dispatcher.Invoke 仍然显示带有异常信息的用户友好对话框。

正如我们在 .net 4.5 中所知道的那样，UnobservedTaskException 不会使应用程序崩溃。

为了使开发人员更容易编写基于任务的异步代码，.NET Framework 4.5 更改了未观察到的异常的默认异常行为。尽管未观察到的异常仍然会引发 UnobservedTaskException 异常，但默认情况下进程不会终止。相反，在引发事件后由运行时处理异常，无论事件处理程序是否观察到异常。可以配置此行为。从 .NET Framework 4.5 开始，您可以使用配置元素恢复到 .NET Framework 4 的行为并终止进程：

好吧，假设微软决定改变多线程处理异常的体验，但为什么它只适用于 tpl 呢？为什么多线程机制的其他部分没有改变？例如，以下代码仍然会使应用程序崩溃

这很混乱，看起来很奇怪。有人知道这件事吗？

我有一个非常奇怪的问题，现在这是我的代码：

让我抓狂的是，为什么“UnobservedTaskException”的事件不能被捕获？我使用了 GC.Collect() 和 Thread.Sleep()，但没有任何帮助……？

有时，没有创建“Error.txt”，有时，创建的文件没有任何内容......？

【已解决——现在根据建议，给你答案】</p>

1）请注意，我应该删除“取消”并在此处模拟异常：

2）然后展平异常（因为这是一个聚合异常）：

假设我有一个带有 Main 方法的控制台应用程序，如下所示：

所以，我只是运行 MyAwesomeMethod（即发即弃），并想做一些其他工作，但我也想知道是否有任何未处理的异常。但是应用程序成功完成，没有任何问题迹象（只是吞下了异常）。

如何在不等待或使用 Task.Run(...).Wait() 的情况下处理来自 MyAwesomeMethod() 的异常？

以下代码在 netcoreapp2.0 应用程序中运行时，似乎最终不会抛出UnobservedTaskException

这是项目文件。我怎样才能让UnobservedTaskException处理程序被解雇？

在其他 stackoverflow 帖子中，我看到了在项目文件中使用以下代码段的建议，但它仅适用于 .net 框架 4.0+ 项目。如果有 .netcore 项目文件的等效文件，那可能就是我需要知道的。

I have a C# webapi project that is communicating as a signalr client with another application. Periodically it throws this exception which causes it to crash. I can reproduce the exception by running some load tests on it, but despite searching high and low I can't pinpoint where this exception is occurring and prevent it.

My application is .net 4.7 and the signalr hub is running .net 4.7. I'm pretty sure the server is not involved. If I restart the client, it picks up where it left off and continues working.

There are a number of async methods in the webapi client, and I've confirmed that all the ones called internally are awaited and they all have exception handlers in them. The webapi endpoints are also marked async.

I've spent a few days trying to get to the bottom of this exception. Any tips would be gratefully accepted! Happy to elaborate with more info as needed.