問題タブ [unobserved-exception]

.NET 4.0 でTPL ( Task Parallel Library ) を使用しています。Thread.GetDomain().UnhandledExceptionイベントを使用して、未処理のすべての例外の処理ロジックを一元化したいと考えています。ただし、私のアプリケーションでは、TPL コードで開始されたスレッドに対してイベントが発生することはありませんTask.Factory.StartNew(...)。のようなものを使用すると、実際にイベントが発生しnew Thread(threadStart).Start()ます。

この MSDN の記事では、TPL を使用するときに Task.Wait() を使用してキャッチすることを提案していますAggregateExceptionが、このメカニズムは十分に「集中化」されていないため、これは私が望んでいることではありません。

誰かがまったく同じ問題を経験していますか、それとも私だけですか? これに対する解決策はありますか？

この例外を引き起こす条件を再現しようとしています:

私は例外を引き起こすだろうと考えてこのプログラムを書きましたが、そうではありません:

私の実際のアプリケーションでは TPL を使用していますが、例外処理のコードを書いていません。その結果、その例外が発生します。現在、別のプログラムで同じ条件を再作成して、観察されていない例外を実験しようとしています。

UnobservedTaskExceptionファイナライザーがオブジェクトで実行されているときに、監視されていない例外がアプリケーションを終了するのを防ぐために、を処理できることを知っています。

ただし、このイベントのハンドラーをいつ、どこに設定すればよいかわかりません。TaskSchedulerクラス内のイベント自体に関する XML ドキュメントには、次のように記載されています。

これは、AppDomain 全体で 1 つのハンドラーしか必要ないということですか? そして、監視されていないすべてのタスク例外がそれによって処理されるということですか?

または、アセンブリごと/クラスごとにハンドラーが必要で、そのアセンブリ/クラス内のタスクからの監視されていない例外のみがそのハンドラーに送られますか?

エラーを処理するための継続的なタスクがあります。

継続がヒットしましたが、数秒後、アプリケーションで次のエラーが発生しました。

タスクの例外は、タスクの待機またはそのExceptionプロパティへのアクセスのいずれによっても観察されませんでした。その結果、監視されていない例外がファイナライザスレッドによって再スローされました。

これはuiSchedulerに関連していますか？同様の質問の解決策は、基本的に私が行っていることです 。タスクの例外は、タスクの待機またはそのExceptionプロパティへのアクセスのいずれによっても観察されませんでした。その結果、観察されなかった例外は

失敗した統合テストを介して観察している断続的な問題をデバッグしようとしていますが、岩と困難な場所の間で立ち往生しているようです。

どこかで何かが作成され、System.Threading.Tasks.Taskその後失敗し、監視されていないタスク例外が発生します。結果のハンドラーで、タスク ID と失敗の原因となった例外を確認できます。私は苦労して自分のコードを分析し、自分のアドバイスに従い、すべてのタスクに名前を付けましたが、まだ問題のあるタスクを見つけていません。私のコードがそれをまったく作成していないようです。

そこで、Taskコンストラクター自体にブレークポイントを設定してみました。これは、関数ブレークポイント (「System.Threading.Tasks.Task.Task(System.Action)」などの場所) を使用して行うことができます。これは機能し、デバッガーが壊れて、Taskクラスのアセンブリが表示されます。ただし、実際に行う必要があるのは、 の ID を の ID に関連付けて、Task失敗Taskすることです。

そのために、Task.Idプロパティをトレース ポイントに出力してみます。しかし、メソッドが最適化されているため、式を評価できないというメッセージが表示されます。

ということで、ソースでデバッグしてみました。すべてのシンボルと what-have-you をセットアップしましたが、できることはすべて試しましたが、うまくいきません。多くのグーグル検索の後、最新の .NET 4 ではサポートされていないことがわかりました。

この問題を診断する方法について誰か考えがありますか?

タスクの配列があり、taskArray使用してタスクの継続を作成しContinueWhenAll、1 つ以上のタスクがtaskArray例外をスローするとします。私の質問は、これがにつながる可能性のあるシナリオはありますUnobservedTaskExceptionか?

つまり、基本的に質問は、単一のタスクに対して行うようContinueWhenAllに例外を観察しますか? いいえの場合、各タスクの例外を明示的に見たくない場合は、タスクのグループに何を使用する必要がありますか。一般的なタスクには使用できないため、使用したくありません。taskArrayWaitWaitAll

これは、「C# 5.0 in a Nutshell」のサンプル コードです。

VS2012 設定で「CLR 例外」: 「ユーザー未処理でブレーク」オプションをチェックして、このコードを実行すると、VS の「NRE 例外がユーザー コードによって処理されませんでした」というポップアップが表示されます。throw null;

ContinueWith 以降の Wait で例外を try-catch しようとしましたが、未処理の例外が発生しました。

「CLR例外」を有効にするソリューションのように感じます：「ユーザー未処理のブレーク」をオフにすると、実際にこの例外を処理するため、間違っているようです。では、それを管理する正しい方法は何ですか？

ホスティング プロセスがクラッシュしないように、タスクで使用できる C# 拡張メソッドを使用して、スローされた例外が最小限に抑えられるようにします。.NET4.5 では、動作がわずかに変更されたため、これは発生しませんが、監視されていない例外イベントは引き続きトリガーされます。ここでの私の課題は、拡張メソッドが機能することを証明するテストを作成することです。私は NUnit テスト フレームワークを使用しており、ReSharper がテスト ランナーです。

私が試してみました：

でのテストは常に失敗しますAssert.IsTrue。このテストを LINQPad などで手動で実行すると、期待どおりの動作がwasUnobservedException返されtrueます。

TaskScheduler.UnobservedTaskExceptionテストフレームワークが例外をキャッチし、それがトリガーされないように監視していると推測しています。

次のようにコードを変更してみました。

このコードで試みたのは、例外がスローされる前にタスクが GC されるようにすることでした。これにより、ファイナライザーはキャッチされず、監視されていない例外を確認できます。ただし、これにより、上記と同じ失敗が発生しました。

実際、テスト フレームワークによって何らかの例外ハンドラが接続されているのでしょうか。もしそうなら、それを回避する方法はありますか？それとも、私は何かを完全に台無しにしていて、これを行うためのより良い/簡単/クリーンな方法がありますか?

最近、バックエンド API アプリですべての UnobservedTaskException のエラー ログを追加しました。その理由は、一部の API 呼び出しが、結果を返した後に終了する追加のタスクを実行するためです。そのため、アクション (Web API 呼び出し) レベルでエラーを追跡できませんでした。

現在、「操作がキャンセルされました」という例外が多数発生しており、どうすればよいかわかりません。この例外が、API 呼び出しによって実行されたタスクによって引き起こされているかどうかさえわかりません。

ここにスタックがあります：

それをデバッグする方法はありますか？