問題タブ [threadabortexception]

System.Threading.TimerSQL Server から定期的にデータを更新するために使用している があります。時折、タイマーのスレッドが異常終了し、ThreadAbortExceptions が発生することがあります。

現在、これらの例外はGlobal.asax.csApplication_Error メソッド/ハンドラーで処理しています。

ただし、このエラーを実際のタイマーの近くで処理したいので、ログに記録するだけでなく、実際に何かを行うことができます。

しかし、それは私には明確ではありません.Timerでこれらのイベントを監視するにはどうすればよいですか?

編集:私が得ている実際の例外:

Thread.Abort を使用して、あるマネージド スレッドから別のマネージド スレッドを中止する場合、CLR は実際にどのようにして他のスレッドで例外をスローするのでしょうか? 巧妙なトリックのようです！

こんにちは、次のテスト コードがあります。

毎回、中止が発生すると、 Thread.ResetAbort() が実行されます。この ResetAbort は何をするのだろうか。実行すると、次の出力が表示されたからです。I will come back! 戻ってきます！戻ってきます！そして、出力「End」が表示されませんでした。このプログラムはまったく終了していないようです。なぜなのかご存知ですか？ありがとう！

に設定されているSystem.Timers.Timerタイマーがあります。私はそれの終わりにタイマーを保証するためにを使用します（私は実行の重複を防ぐためにこのようにタイマーを使用します）。コード：AutoResetfalsetry/finallyStartcallbackcallback

私の質問は、実行中のスレッドがである場合はどうなりAbortedますか？セクションはまだ実行されていますか、finallyそれともその部分を実行するスレッドがありませんか？

私はコードの例外安全性の改善に取り組んでおり、C#コンストラクトThreadAbortExceptionでリソースを保護している場合でも、raise によって望ましくないリソース リークが発生する可能性があることに気付きました。usingたとえば、次のコードを考えてみましょう (別のスレッドで実行されている可能性があります)。

このコードを実行しているスレッドが異常終了した場合は、 が参照するファイル ハンドルfilenameをすぐに閉じてください。usingコンストラクトの使用を try/finally ブロックに置き換えずにこれを行うことはできますか?

これは、いつでも発生する可能性があるということです。つまりThreadAbortException、ステートメント間で何が起こっているかに注意を払う必要があります。CreateWritertry/finally ブロックを使用して例外を防ぐことはできますが、括弧内の式が評価されるまで構造は同じことを行いません。つまり、リターンusingの直後に例外が発生した場合、ファイル リソースは開いたままになります。CreateWriter

ThreadAbortExceptionファイナライザーが最終的にファイルハンドルを解放することは理解していますが、使用されている各場所でキャッチせずにこの問題に対処する決定論的な方法があるかどうか疑問に思っていますCreateWriter.

私が見つけた Excel コードへの変換に問題があります。私は.NET 4.0でWebサイトプロジェクトに取り組んでおり、次のことを行うクラスを作成しました( http://mattberseth.com/blog/2007/04/export_gridview_to_excel_1.htmlに基づく):

ページに表示される GridView に追加されるボタンを含むユーザー コントロールからこのクラスを呼び出します。これは期待どおりに機能します。ボタンをクリックすると、GridView からのデータを含む結果の Excel スプレッドシートを開くか保存するためのダウンロード オプションが表示されます。

ただし、別の GridView 内の linkbutton からこれを呼び出すと、動的なグリッドビューを作成してデータを格納し、それをエクスポートしたいと考えています。これを行うと、クラスの Response.End 呼び出しから ThreadAbortException が発生します。

質問 1: ユーザー コントロール内から同じコードを呼び出したときに ThreadAbortException が発生しないのはなぜですか? ユーザーコントロールは独自のスレッドまたはその他の種類のコンテキストを取得しますか?

その ThreadAbortException が発生したときに発生するエラーを検索すると、それを ApplicationInstance.CompleteRequest() に置き換えようとしました。これを行うと、ThreadAbortException を取得しなくなりましたが、これにより、以前に機能していたユーザーコントロールが壊れます。グリッドからのデータを含む結果の Excel スプレッドシートではなく、含まれているページの HTML が含まれており、とにかく簡単に抑制できます。空のキャッチでそのエラー。ただし、動的に生成された GridView を使用した直接呼び出しは修正されません。そのコードは、「サーバーから受信したメッセージを解析できませんでした」という JavaScript エラーをレンダリングします。

ここで何が起こっているのか正確に理解したいのですが、理解に関係なく結果が必要なところです。私が試した他のすべてのアプローチ（GridViewの代わりにデータグリッドなど）は同じ問題に遭遇し、現在の応答を「引き継ぎ」、stringwriterとhtmlwriterを使用してデータをExcel contentType で応答します。そして、これはユーザーコントロールのコンテキストで明らかに機能するため、直接呼び出されたときに機能しない理由について、私は機知に富んでいます...

ASP.NET アプリケーションで、夜間のリサイクルによって w3wp がハングすることがあるという問題に遭遇しました。

これが起こることです：

リサイクルがトリガーされます。明らかに、これは実行中のすべてのスレッドで ThreadAbortException を強制します。ただし、新しい w3wp をトリガーするようには見えないか、実際に例外をスローするのは新しい w3wp です (まだ再現できていません)。

私のログでは、大量の ThreadAbortException が発生し、スレッド カウントが無制限に増え続けています。つまり、新しいリクエストが終了しない新しいスレッドを生成することを意味します。これが古い w3wp だった場合、新しいリクエストは新しく開始された w3wp にルーティングされます。

シャットダウン タイムアウトもラピッド フェール保護もトリガーされないようで、手動でリサイクルされるまでサイトを使用できません。ほとんどの場合、CPU も大量に消費し、サーバーもほとんど使用できなくなります。

おそらくそれとは何の関係もないモノレール MVC を使用していますが、RescueController システムを利用しています。エラー処理で意図せずに ThreadAbortException をキャッチした場合、無限ループが発生し、w3wp がひどくハングして IIS が回復できなくなる可能性はありますか?

スレッドを使用して、重みを読み取るためのwhileループを含む関数を呼び出しています。whileループでは、デリゲート関数を呼び出してテキストボックスの値を更新しています。

、という名前のボタンをクリックするとStop、スレッドを中止しようとしていますが、スレッド中止の例外が発生します。

上記のコードでは、スレッドアボート例外が発生しています。この問題を解決するために誰か助けてください。

本「Windowsでの並行プログラミング」から次のコードを取得しました。

CLR が ThreadAbortException を再スローする理由を知ることに興味がありますか? そして、「Thread.ResetAbort()」を呼び出すまでそれを続けます。第二に、 CLR から特別な扱いを受ける他のシステム定義の例外はありますか?

DotNetOpenAuth -3.4.7.11121で System.Threading を受け取ります。DotNetOpenAuth.OpenId.RelyingParty.IAuthenticationRequest RedirectToProvider () メソッドの呼び出し時に ThreadAbortException が発生する。私のコールスタックは次のようになります

" で System.Threading.Thread.AbortInternal()\r\n で System.Threading.Thread.Abort(Object stateInfo)\r\n で System.Web. HttpResponse.End() \r\n で DotNetOpenAuth.Messaging. c:\BuildAgent\work\a02b428f36957bca\src\DotNetOpenAuth\Messaging\OutgoingWebResponse.cs:line 161\r\n の OutgoingWebResponse.Send(HttpContext context) c:\BuildAgent\work の DotNetOpenAuth.Messaging.OutgoingWebResponse.Send() \a02b428f36957bca\src\ DotNetOpenAuth \Messaging\OutgoingWebResponse.cs: 131 行目\r\n at DotNetOpenAuth.OpenId.RelyingParty.AuthenticationRequest.RedirectToProvider ()

これを防ぐにはどうすればよいですか？