問題タブ [contextswitchdeadlock]

VS 2008 でプログラムをデバッグしているときに、次のエラーに遭遇しました。

CLR は、60 秒間、COM コンテキスト 0x34fc1a0 から COM コンテキスト 0x34fc258 に移行できませんでした。宛先コンテキスト/アパートメントを所有するスレッドは、非ポンピング待機を行っているか、Windows メッセージをポンピングせずに非常に長時間実行されている操作を処理している可能性があります。この状況は通常、パフォーマンスに悪影響を及ぼし、アプリケーションが応答しなくなったり、メモリ使用量が時間の経過とともに継続的に蓄積したりする可能性さえあります。これを避けるには

コードには単純な C# タイマーしか含まれていませんが、デッドロックしているように見えます: 以下のスニペットを参照してください:

タイマーが実行され、経過してから再び初期化される必要があることを知っている限り、デッドロックのローカルな理由はわかりません。

このエラーメッセージをオフにする方法は知っていますが、これは解決策ではなく、問題を隠していると感じています。

奇妙なエラーがあります：

Managed Debugging Assistant'ContextSwitchDeadlock'は、'C：\ Documents and Settings \ Lena G \ My Documents \ SchoolStuff \ IR Information \ Home Work \ FianlProject \ finalProject \ finalProject \ bin \ Debug\finalProject.vshost.exe'で問題を検出しました。追加情報：CLRは、COMコンテキスト0x3407968からCOMコンテキスト0x3407ad8に60秒間移行できませんでした。宛先コンテキスト/アパートメントを所有するスレッドは、ほとんどの場合、非ポンピング待機を実行しているか、Windowsメッセージをポンピングせずに非常に長時間実行されている操作を処理しています。この状況は一般にパフォーマンスに悪影響を及ぼし、アプリケーションが応答しなくなったり、メモリ使用量が時間の経過とともに継続的に蓄積したりする可能性さえあります。この問題を回避するには、

このエラーでは、実行または中断を続行できます。続行すると、正常に実行されますが、それでも心配です。いくつかのテキストを含むxmlファイルを読み取り、その単語をハッシュテーブルに配置してから、ハッシュから通常のテキストファイルに書き込むプログラムがあります。

誰かがこの問題を解決するのを手伝ってくれるかどうかを確認してください。

前もって感謝します、

レナ

O / S Thread.Sleep（10）を実行せずに、協調型/非プリエンプティブなマルチタスクで歩留まりやスリープのデッドロックを回避するための創造的なアイデアはありますか？通常、yieldまたはsleep呼び出しは、他のタスクを実行するためにスケジューラーにコールバックします。しかし、これによりデッドロックが発生する場合があります。

いくつかの背景：

このアプリケーションにはスピードに対する大きなニーズがあり、これまでのところ、同じ業界の他のシステムと比較して非常に高速です。速度の手法の1つは、O / Sスレッドからのコンテキストスイッチのコストではなく、協調的/非プリエンプティブなスレッド化です。

高レベルは、優先度と処理時間に応じてタスクを呼び出す優先度マネージャーを設計します。各タスクは1回の「反復」作業を実行し、優先キューで再び順番を待つために戻ります。

非プリエンプティブスレッドのトリッキーなことは、特定のタスクを作業の途中で停止し、別のタスクからの他のイベントを待ってから続行する場合にどうするかです。

この場合、ABとCの3つのタスクがあります。ここで、AはBとCのアクティビティを同期する必要があるコントローラーです。最初に、AはBとCの両方を開始します。次に、Bが降伏するため、Cが呼び出されます。Cが降伏すると、Aは両方が非アクティブであることを確認し、Bを実行する時間であると判断しますが、Cの時間はまだ決定しません。さて、BはCと呼ばれる歩留まりで立ち往生しているので、実行することはできません。

ここで非常に奇妙なバグに直面していますが、それを解決するための正しい道をたどっているのか、それともどのように解決しているのかさえよくわかりません。

これが私が直面している問題です: log4net、NHibernate、LINQ to NHibernate を使用する WPF アプリケーションのデバッグを開始し、データベースからエンティティを取得しようとすると、アプリケーションと VS が長時間ハングし、その後しばらくすると、例外ダイアログが開き、ContextSwitchDeadlock MDA に関する次の情報を含むメッセージが表示されます。

CLR は、60 秒間、COM コンテキスト 0x34fc1a0 から COM コンテキスト 0x34fc258 に移行できませんでした。宛先コンテキスト/アパートメントを所有するスレッドは、非ポンピング待機を行っているか、Windows メッセージをポンピングせずに非常に長時間実行されている操作を処理している可能性があります。通常、この状況はパフォーマンスに悪影響を及ぼし、アプリケーションが応答しなくなったり、時間の経過とともにメモリ使用量が継続的に蓄積したりする可能性さえあります。これを避けるには

コード ファイルを新しいプロジェクトにコピーし、古いプロジェクトを削除して、構成に関係があると考えて、このメッセージを消すことができるかどうかを確認しました。何が原因なのかを確認するために一度にいくつか追加し始めました.log4net構成コードを含めると、バグが再び現れました. 最初に、AssemblyInfo を介してそれを含め、後でアプリケーションの起動時にコード構成を介して含めましたが、まったく何も変更されていません :(

だから、ここに私の発見があります：

• log4netを使用している場合にのみ発生します。
• これは、NHibernate がデータベースからエンティティをロードする (遅延ロード) ときに発生します。

このバグの原因が何であるかはわかりません。Visual Studio でのデバッグ時にのみ発生します。次のページの「MDA の有効化と無効化」セクションの手順に従ってみました: http://msdn.microsoft.com/en-us/library/d21c150d.aspx、VSそれでもハングし、メモリ使用量が増加します。

プログラムを通常実行すると、これは何も起こらないので、この質問が示唆するように、これはデッドロックの状況ではないと確信しています: contextswitchdeadlock (私はそこに投稿された解決策も試しました)。

そのため、log4net を無効にして、アプリをデプロイするときに再度有効にすることにしました。

この質問を投稿して、他の誰かがこのバグに直面したかどうか、または解決方法について提案があるかどうかを確認します。最後に、このまったく同じ問題に直面している他の誰かを助けるかもしれません.

だから私はユニットテストを実行しています、それは実行するのに長い時間がかかる「悪い」ユニットテストです。（以前は問題なく機能していました）

現在、コンテキストスイッチのデッドロックが検出されたというエラーが発生しています。テスト全体を実行するのに非常に長いプロセス（20分）があるため、推測しています。

ここで説明されているように：http： //bytes.com/topic/c-sharp/answers/471705-context-switch-deadlock-detected

ユニットテストをエラーなしで実行するためにできることはありますか？

他に何もない場合は、テストから取り出してlittelラッパーアプリを作成できますが、これらのテストは年に1〜2回しか実行しないため、多くの作業が必要になるようです...

ありがとう、

Cal-

基本的にyahoo smtpサーバーを介して電子メールを送信できる小さなプログラムを作成しました。私のコード:

奇妙なことに、最初の 1 週間は効果がありました。問題なくメッセージを送信できました。それからちょうど昨日、プログラムがフリーズし始めて応答しません（コードを変更していません）。なぜこれが起こったのですか？プログラムを修正するにはどうすればよいですか?

編集: @Andreas Niedermair 今、プログラムを試してみて、1 分間放置したところ、エラーが表示されました:ContextSwitchDeadlock が検出されました メッセージ: CLR は、COM コンテキスト 0x21eb78 から COM コンテキスト 0x21ece8 に 60 秒間遷移できませんでした。宛先コンテキスト/アパートメントを所有するスレッドは、非ポンピング待機を行っているか、Windows メッセージをポンピングせずに非常に長時間実行されている操作を処理している可能性があります。この状況は通常、パフォーマンスに悪影響を及ぼし、アプリケーションが応答しなくなったり、メモリ使用量が時間の経過とともに継続的に蓄積したりする可能性さえあります。この問題を回避するには、すべてのシングル スレッド アパートメント (STA) スレッドでポンピング待機プリミティブ (CoWaitForMultipleHandles など) を使用し、実行時間の長い操作中に定期的にメッセージをポンピングする必要があります。

ご協力いただきありがとうございます！

私が得る完全なエラーは次のとおりです。

CLR は、COM コンテキスト 0x1a8188 から COM コンテキスト 0x1a8018 に 60 秒間遷移できませんでした。宛先コンテキスト/アパートメントを所有するスレッドは、非ポンピング待機を行っているか、Windows メッセージをポンピングせずに非常に長時間実行されている操作を処理している可能性があります。この状況は通常、パフォーマンスに悪影響を及ぼし、アプリケーションが応答しなくなったり、メモリ使用量が時間の経過とともに継続的に蓄積したりする可能性さえあります。この問題を回避するには、すべてのシングル スレッド アパートメント (STA) スレッドでポンピング待機プリミティブ (CoWaitForMultipleHandles など) を使用し、実行時間の長い操作中に定期的にメッセージをポンピングする必要があります。

これが何を意味するか分かりますか？そして、どのように解決すべきですか？Google で検索してみましたが、特定のシナリオに関連するものは何も見つかりませんでした。

編集: 特定のシナリオ: 1. WPF を WinForms に統合する 2. WPF 画面はプラグイン dll 用に作成され、メイン アプリケーションに動的にロードされます。

ありがとう

ハサナイン

AC＃コードはC ++ dllからプロパティ値を取得し、この取得はdllが値を返すまで現在のスレッドをブロックします。デバッグモードでは、取得に時間がかかる場合、MDAはContextDeadlockSwitchをスローします。

実行時にContextDeadlockSwitchをキャッチすることはできないと思いますが、MDAと同様のメカニズムが、C＃がキャッチしてこのデッドロックを検出できる同様の例外をスローする方法はありますか？

その理由は、C＃コードでユーザーにプロンプ​​トを表示して、さらに数秒待つか、アプリを強制的に強制終了して再起動するようにするためです。

私は通常長い時間がかかる複雑な計算を実行するC＃（.net 3.5 cp、vs2010）のクラスを持っています。1 分後、ContextSwitchDeadlock が検出されたという例外がスローされます。例外は英語以外の言語にローカライズされているため、コピーして貼り付けることはできませんが、意味は次のとおりです。 ¨ CLR モジュールは、コンテキスト COM ... からコンテキスト COM ... に 60 秒間遷移できませんでした。ターゲット コンテキスト/アパートメントを所有するサブプロセスは、おそらく非ポンピング待機を行っているか、Windows システム メッセージをポンピングせずに非常に長時間実行される操作を処理しています。

基本的に、私のアプリケーションはコンピューティングを行っていて、長い間ウィンドウに応答していないようで、ビジュアル スタジオはそれをシャットダウンし、デッドロックの可能性を報告します。

私はいくつかの調査を行おうとしており、2つの解決策を見つけました。

1. デッドロックを検出するために、Visual Studio デバッガーの一部のオプションを無効にします。デバッグ目的でのみ機能するため、機能しません。

2. いくつかの DoEvents メソッドを呼び出しますが、それは WPF ではなく Windows フォーム用であり、私は WPF を使用しています。

別のスレッドを作成するという提案もありましたが、私はスレッド化がまったく初めてで、どうすればよいかわかりません。何か提案はありますか？

簡単に言うと、COM inproc-server（dll）で動作するC＃アプリケーションで、「0x80010100：システムコールに失敗しました」という例外が発生し、デバッグモードでもContextSwitchDeadlock例外が発生します。

詳細は次のとおりです。

1）C＃アプリはSTAを初期化し、COMオブジェクト（「Apartment」として登録）を作成します。次に、inはその接続ポイントにサブスクライブし、オブジェクトの操作を開始します。

2）ある段階で、COMオブジェクトは多くのイベントを生成し、同じアパートで作成されたCOMオブジェクトの非常に大きなコレクションを引数として渡します。

3）C＃側のイベントハンドラーは上記のコレクションを処理し、オブジェクトのいくつかのメソッドを呼び出すことがあります。ある段階で、後者の呼び出しは上記の例外を除いて失敗し始めます。

COM側では、アパートはwinprocが次のように見える非表示のウィンドウを使用します。

イベントは、COMサーバーの他の部分からこのウィンドウに投稿されます。

イベントは、実際のパラメータにバインドされた標準のATL CP実装であり、要約すると次のようになります。

C＃では、ハンドラーは次のようになります。

==================

それで、アパートのメッセージキューが配信しようとするイベントでいっぱいになっているという理由だけで、上記の問題が発生する可能性がありますか？または、そのような動作を引き起こすために、メッセージループを完全にブロックする必要がありますか？

メッセージキューに、「onEvent」呼び出しと評価される2つの連続したイベントがあると仮定します。最初のコードはC＃マネージコードを入力します。これは、同じアパートであるアンマネージコードを再入力しようとします。通常、これは許可されており、私たちはこれを頻繁に行います。いつ、どのような状況で失敗する可能性がありますか？

ありがとう。