問題タブ [debugdiag]

WinDBG を使用して、実稼働マシンの 1 つからのクラッシュ ダンプを分析しようとしています。私の問題の根本は、実稼働マシンとは異なるビルドの .NET フレームワークを使用していることにあるようですが、問題を解決する方法がわかりません。!sym ノイジーにしてから !dlk (SOSEX から) を実行すると、mscordacwks dll を見つけようとして次のエラーが発生します。

mscorwks.dll、mscordawks.dll、および sos.dll を運用マシンから取得し、C:\mysymbols に配置しました。WinDBG が mscorwks dll 内の dll を探しているようです。

Windows 2008 R2 を使用していますが、CPU は 100% です。担当のアプリ プールで DebugDiag を実行したところ、次のコール スタックが見つかりました。

私の質問は、このスレッドを生成したコンポーネントを特定したいので、このスレッドが Telerik アプリケーションからのものなのか、開発者の 1 人が作成したものによって制御されているのかを知りたいということです。

このスレッドを生成したオブジェクトを特定するにはどうすればよいですか?

私は Web アプリケーションを持っていますが、ハングアップしたり、パフォーマンスが非常に遅くなったりすることがあります。DebugDiag を使用して完全なダンプを取得し、クラッシュ/ハング分析を使用して分析を試みました。

要約によると、スレッドの 7.86% (10) がブロックされ、Monitor.Wait.

しかし、スレッドでコール スタック/スタック トレースを確認すると、以下が出力されます。

彼らがどのロックを取得するのを待っているかは実際には表示されません-この情報を取得する方法について何か考えはありますか?

アプリ プールは 1 日に数回リサイクルされます。メモリの制限に達したためだと確信しています。また、最大 3 GB のメモリ制限に達するべきではないと確信しています。WinDbg を使用してメモリ ダンプを分析しようとしましたが、ほとんど成功しませんでした。後でもう一度試すかもしれません。ただし、DebugDiag を使用すると、データをうまく視覚化でき、リサイクルの回数を減らすいくつかの変更が既に行われています。私が少し混乱し、心配しているレポートの 1 つは、HttpContext レポートです。次のような出力が表示されます。

もちろん、レポートにはさらに多くの行があります。995 秒 (~15 分) 実行されていて、まだ完了していないリクエストが本当にあるのでしょうか? 彼らはそこに吊るされているだけですか？彼らは何か他のものが終わるのを待っていますか？診断を開始するどころか、信じることができるかどうかもわかりません。このデータを解釈する方法について、他の誰かが私に洞察を与えることができますか?

時々ハングしているように見える.Net 4.0 WPFアプリケーションがあります（1日に1〜2回）。アプリケーションはすべて、ユーザー アクティビティの監視に関係しているため、多くのネイティブ コール (EnumWindows、GetForegroundWindow、GetLastInputInfo など) を使用します。また、このアプリケーションは、SQL Server CE 4.0 データベースを使用して情報の一部を保存します。

これらのハングの 4 ～ 5 件からクラッシュ ダンプを取得することができました。それらはすべて非常によく似ていますが、問題の原因を突き止めるのにまだ苦労しています。

以下に、最新のクラッシュ ダンプの DebugDiag 分析の結果を示します。これの約 20 秒前に取得されたクラッシュ ダンプは、まったく同じ結果を示しました。このことから、他のスレッドを待機させている 2 つのスレッドがあるように見えます。

17 - このスレッドは、CE データベースにデータを挿入しています。このスレッドがハングする理由がわかりません。

22 - スタックトレースから、このスレッドが何をしているのかわかりません。

アプリケーションは、いくつかの場所で System.Threading.Tasks を大量に使用してタスクを開始し、さまざまなイベントを処理するため、非常に多くのスレッドが存在する可能性があります。一部の読み取りでは、Thread 22 は LoaderLock の問題のように見えますが、私は DllImport を介して標準の Windows API 呼び出しを使用しており、カスタム C++ コードはありません (通常、この問題が発生するようです)。

現時点で私は少し立ち往生しているので、アドバイスや指針をいただければ幸いです。

大きすぎるため、完全な DebugDiag 結果を投稿することはできませんが、最も重要と思われる部分を以下に示します。

おそらくこれに対する簡単な答えがあるように感じますが、見つけることができませんでした。

問題のシナリオは、C# .NET コンソール アプリです。

私は通常、DebugDiag 1.2 を使用して、経験したハングに起因する .dmp ファイルを調べます。通常は、スレッド ロックの問題です。それらは、DebugDiag の「Create Full Userdump」オプションを使用して作成されます。

私は最近、.NET 4 の機能の一部を使い始める準備として、.NET 4 をターゲットとするアプリのコンパイルを開始しました。しかし、これらの .dmp ファイルを DebugDiag で分析すると、.NET スタック情報がすべて欠落していることに気付きました。

CLR ターゲットを .NET 3.5 に戻し、新しい実行可能ファイルから .dmp をキャプチャすると、.NET コール スタック情報が表示されます。

DebugDiag の出力を見ると、次のようなメモが表示されます。

CLR 情報

CLR バージョン = 4.0.30319.17929 CLR デバッガー拡張機能 = C:\Program Files\DebugDiag\Exts\psscor4.dll

.NET スレッドのまとめ

ThreadStore のリクエストに失敗しました

.NET 3.5 .DMP ファイル (psscor2.dll を使用) は、「Threads Summary」ヘッダーの下にすべてのスレッド情報を報告するため、「Failed to Requested ThreadStore」が問題の鍵であると推測します。

.dmp に情報が欠落している、または DebugDiag が何らかの理由で情報を取得できないという問題ですか?

おそらくこれは正常な状況ですが、私は混乱しています。

Visual Studio から C# Debug アプリケーションを実行しています。DebugDiag は、プロセスに自動的にアタッチするように設定されています。

このアプリケーションからクラッシュ ダンプを収集するルールがあり、このルールでは、未構成の初回例外に対するアクションを「なし」にする必要があると定義しています。

しかし、アプリケーションがクラッシュし、ダンプ ファイルを見ると、最初のチャンスの例外があると表示されます。

このSOの質問への回答から、「例外は最初にデバッガーにスローされ、次に実際のプログラムにスローされ、処理されない場合はデバッガーに2回スローされる」ことを理解しています

では、なぜ DebugDiag は初回例外のダンプ ファイルを収集するのでしょうか?

編集 明確にするために、ここで壊れたコードを修正しようとしているわけではありません。初回例外によりコードがクラッシュしたと DebugDiag が通知した理由を理解しようとしています。確かに定義上、2 回目の例外だけがコードをクラッシュさせる可能性があります。つまり、コードによって処理されていない例外ですか?

「crash」は、プロセスが終了し、DebugDiag がクラッシュ ダンプ ファイルを生成したことを意味します。「デバッグなしで開始」でコードのデバッグバージョンを実行していました