問題タブ [threadabortexception]

ファイルをダウンロードした後、さらにコードを実行する必要がありますが、実行されません。ClearControls();コンパイラは の後にヒットしDownloadFile();ますが、関数は実行されません。ページで、ファイルを開くか保存するように求めるプロンプトが表示されます。しかし、テキストボックスはクリアされません。この場合、何をすべきか。

サービス参照で CancelTransactionByRefPos という名前のメソッドを呼び出す必要があります。このメソッドには次のシグネチャがあります。

このメソッドが「0」を返す場合、キャンセルは成功です。このメソッドが別の値を返す場合、メソッドを再度呼び出す必要があります。

CancelTransactionByRefPos を呼び出す Cancel メソッドを作成しました。応答が返されるまでに 30 秒かかる場合があるため、呼び出しが非同期で行われることが非常に重要です。

私の方法は次のようになります。

コメントの task.Wait() 部分でキャンセルすると、ThreadAbortException が発生します。

task.Wait() のコメントを外して再度実行すると、すべてうまくいきますが、タスクが実行されるまで待たなければならない場合は、メソッドを非同期で呼び出しても意味がありません。

編集

また、サービス参照を構成して、非同期操作を生成できるようにしました。同じ問題。

Thread.Abort を呼び出したときに最終ステートメントが実行されない理由を知っている人はいますか? 次のようなスレッド関数があります。

Thread.Abort を使用してこのスレッドを終了します。出力に表示されるのは一連の Waiting だけですが、他の行はありません。メイン スレッドは Thread.Abort を呼び出した後も実行を続けます (つまり、子スレッドは完了するのに十分な時間があります)。Debug.Log 関数はスレッド セーフです。

これは Windows で発生します。Mono (Unity ゲーム エンジン) を使用しています。Macでは問題なく動作します。iOS ではこの動作が得られますが、デバイス/iOS のバージョンまたは XCode のバージョンに依存しているようです (まだわかりません)。Windowsでは、毎回発生します。

ところで: iOS では、別のtry {} catch {}を finally ステートメントに入れるとクラッシュします。

なぜこれが起こっているのか誰かが知っていますか？Thread.Abort および ThreadAbortException のドキュメントに記載されている内容とはかなり異なるようです。

IIS がホストする WCF サービスがあり、処理する大量のデータを受け取ります。サービスはいくつかのワーカー スレッドを起動し、ワーカー スレッドを残してジョブを終了します (1 時間かかる場合があります)。WCF サービスが長時間アイドル状態の場合、IIS はアプリ プールをリサイクルしてワーカー スレッドを中止します。この問題は、アプリケーション プールを維持するためだけにワーカー スレッドがダミー サービスを呼び出すことで回避されています。このセットアップ全体が本当に悪い考えだと思うなら、私は完全に同意します (私のコードではありません)。だからそれについてコメントする必要はありません。

問題は、時折 ThreadAbortException が発生することです。何が/誰がスレッドの中止を開始したかに関する追加情報を取得する方法はありますか? 私たちのコードではないことはわかっています。

最近、次のスタック トレースでアラートを受け取り始めました。

メッセージ: スレッドは中止されました。

スタック トレース: System.Net.Connection.CompleteStartConnection(Boolean async, HttpWebRequest httpWebRequest) で System.Net.Connection.CompleteStartRequest(Boolean onSubmitThread, HttpWebRequest request, TriState needReConnect) で System.Net.Connection.SubmitRequest(HttpWebRequest request, Boolean forcedsubmit) ) で System.Net.ServicePoint.SubmitRequest(HttpWebRequest request, String connName) で System.Net.HttpWebRequest.SubmitRequest(ServicePoint servicePoint) で System.Net.HttpWebRequest.GetResponse() で 削除され、ID を保護します

リモートサーバーとの実際の接続が確立される前に、スレッドが中止されたようです。本当？なぜそのような状況が発生するのか - 問題を絞り込もうとしています。

メソッドに関するドキュメントを探してみましたが、System.Net.Connection.CompleteStartConnection何も見つかりませんでした。何か案は？

更新: コメントに応じて呼び出しコードの構造を追加します。

更新 2: このアラートは数分間散発的にのみ発生し、その後消えます。

更新 3: まだ提供していない重要な情報 - 更新 1 で表示したコードの一部は、タイマー上のタスクによって呼び出されています。

WCF サービスの実行中に奇妙なエラーが発生します。実行中にスレッドが受信を中止しました。多くの解決策を探しましたが、エラーを下に投稿しても何も役に立ちませんでした。

Web ページから WCF サービスを呼び出しています。WCF サービスは for ループでストアド プロシージャを実行します。これによりスレッドが中止されるかどうか。httpruntime の実行タイムアウトを増やしてみましweb.configたが、成功しませんでした。

AppDomain をアンロードしようとしていますが、CannotUnloadAppDomainException.

MSDN は、この例外がスローされる可能性がある 3 つの理由について言及しています。

1. アプリケーションの有効期間中にロードされたままにする必要がある、既定のアプリケーション ドメイン。
2. 実行をすぐに停止できない実行中のスレッドを持つアプリケーション ドメイン。
3. 既にアンロードされているアプリケーション ドメイン。

私のアプリケーションはケース 2) に苦しんでいます。

バックグラウンド スレッドがいくつかあります。たとえば、独自の Dispatcher を実行する検索インデックス作成スレッドがあります。

私が知る限り、私が電話するとき

次に、影響を受けるドメイン内のすべてのスレッドがThreadAbortException.

理想的には、それはすべてのスレッドが「殺される」/停止することを意味しますよね?

次の 2 つの場合を除きます。

• スレッドがマネージド コードを呼び出すとき - 不運...
• スレッドが finally ステートメントで何らかのコードを実行するとき。

私のアプリケーションが最初に実行しているようです (おそらく、内部で管理されていないコードを呼び出しているため、停止しません)

大きな問題は、複数のスレッドがある場合に AppDomain をアンロードする方法です。

次の 2 つのオプションしか表示されません。

• スレッドを中止してから、どういうわけかスレッドの状態を再確認してください。それらが停止している場合は、呼び出すことができますAppDomain.Unload-例外はスローされません。
• もう 1 つの方法は、単純に callAppDomain.Unloadです。おそらく例外がスローされます。その後、この例外をキャッチして、アンロードを再試行できます。AppDomain.Unload影響を受けるすべてのスレッドを中止しようとするため、おそらく数回の再試行で十分です。

どちらのソリューションも、ハックと思われる再試行メカニズムを使用しています。

.NET でこれを行うための、より簡単で堅牢な方法はありませんか?

この質問を調査した結果: Rethrowing exception in Task doesn't make the Task to go to faulted state、理解できない非常に奇妙な動作に気付きましたThreadAbortException。

今、私はそれThreadAbortExceptionが非常に特別な種類の例外であることを知っています. そして、それが言うとき、ドキュメントはそれについてかなり明確です:

ThreadAbortExceptionキャッチできる特別な例外ですが、catchブロックの最後で自動的に再び発生します。

シナリオ #1 : 文書化された動作。

予想どおり、ThreadAbortExceptionは自動的に再スローされ、次の出力が得られます。

シナリオ #2 : 興味深いのは、catchブロックで別の例外をスローすることにしたときです。

この場合、 がスローされたにもかかわらず、文書化された動作が確実に保持されるようにApplicationException、が再スローされると想定しました。ThreadAbortException驚いたことに、これが結果の出力です。

はApplicationException実際に交換して、投げられるのを防ぎThreadAbortExceptionましたか?!?

シナリオ #3 : 最後に、さらに興味深いことに、既存の例外処理をもう 1 つのtry-catchレイヤーでラップします。

今、私は何を期待すべきかよくわかりません。外側のcatchブロックでキャッチされるのはどの例外ですか? でしょうApplicationExceptionか？もしそうなら、それは私が例外を飲み込み、実際にwill never be reached文字列を出力することができるということですか?

これは実際の出力です:

catch上記の出力から、外側のブロックが実際に をキャッチしているように見えますApplicationException。しかし、その catchブロックの終わりまでにThreadAbortException、突然、何もないところから再び現れて、再び投げ出されますか?

質問: 誰かがシナリオ #2 と #3 を説明し、調整してもらえますか? シナリオ 2 でThreadAbortException、予期せず別の例外に置き換えられたように見えるのはなぜですか? ThreadAbortExceptionしかし、シナリオ #3 では、ずっとそこにいたように見えますか? これはどのように起こっていますか？この動作はどこかに文書化されていますか?