問題タブ [debugdiag]

さまざまなナゲット (autofac、devextreme、automapper、エンティティ フレームワーク) を使用する MVC5 アプリケーションがあります。これらすべてを使用して正常に動作する他の15のMVCアプリがありますが、これは.....

ローカルでは、IISExpress または IIS (Windows 10) で正常に動作します。ただし、Windows 2019 に展開すると、起動時にハングします。ある種のメモリ取得ループに陥っているようです。HTTP 要求が返されず、30 秒後にアプリケーション プールを実行すると、ローカルで最大 200MB を使用する場合に 2GB を超えるメモリが使用されます。

EventLog には何も記録されません。

ロギング (serilog) とトレースを追加しましたが、役に立ちませんでした....スタートアップ コード (global.asax / startup.cs) が正常に実行され、終了します...そして何もありません....最初の http 要求がハングし、すべて後続のキュー。

次にどこを見ればいいのかわからない。私の最後の雹は、DebugDiagをインストールしてダンプを作成することでした-その分析はここにあります

私はDebugDiag / Dumpの専門家ではありません。これは、すべてのスレッドがガベージコレクションを待っているということです...まあ...役に立たない...

誰かがダンプ分析を見て、次に何ができるか/何が起こっているか教えてもらえますか?

概要：

• 一連のメモリ ダンプは、32 ビット プロセス内のメモリ リークの原因を発見する目的で収集されます。
• Debug Diagnostics を使用してダンプを分析しようとすると、2 時間後に失敗し、タイムアウト例外が報告されます。
• 4 時間のタイムアウトを指定する DebugDiag.Analysis.exe.config で「AnalysisCompletedTimeout」パラメータを指定すると、タイムアウト例外が報告されないようにすることに成功します。代わりに、2 時間後に、完全に空のレポートが生成されます。

タイムアウトの問題を回避しようとする私の試みは、部分的にしか成功していないようです。私の質問は、分析を成功させて分析レポートを生成する方法について提案を求めることです。

詳細:

顧客からの要求に応じて、32 ビット COM+ サーバー アプリケーションの一連のメモリ ダンプが提供されました。アイデアは、LeakTrack dll を使用して、このプロセスで観察されたメモリ リークの原因を突き止めることです。

デバッグ診断分析ツールが開始され、ダンプ ファイルが追加されます。「MemoryAnalysis」チェックボックスをチェックすると、分析が開始されます。2 時間後、分析ツールに問題を報告するメッセージ ボックスが表示されます。

JetBrains dotPeek を使用して DebugDiag 分析ツール アセンブリを調べた後、DebugDiag.Analysis.exe.config を変更して、タイムアウト設定を 4 時間に変更してみました。

分析を再試行すると、ツールは再び約 2 時間機能します。完了すると、Internet Explorer が起動され、そのレポートが完全に空白であることが判明します。DebugDiag レポート フォルダーを確認すると、.mht レポート ファイルのサイズが 0 バイトであることがわかります。ただし、今回は「タイムアウト例外」メッセージ ボックスは表示されませんでした。

私が持っている質問は次のとおりです。レポートが生成されないのはなぜですか? デバッグ diag 分析ホスト プロセスまたは呼び出し (UI) プロセスのいずれかで、レポートを完了するために追加または修正する必要がある追加の構成設定はありますか?

他に何が問題なのかを確認するために、分析が開始されたら、windbg をプロセス DebugDiag.x86AnalysisHost.exe にアタッチしました。私の希望は、何が起こっているのかの手がかりを提供できる他の例外条件の証拠を見ることができるかもしれないということでした. ただし、プロセスは制御された方法で終了するように見え、例外条件はありません。

次に行く場所の提案を歓迎します。

.net 4.5 ASP.NET WebAPI アプリケーションがあります。4 CPU の 8 ギガ VM で 1 ワーカーを使用して IIS にデプロイされました。

最近変更を加えました (アップグレードされた ServiceStack.Interfaces、ServiceStack.Common、ServiceStack.Redis、および多数の依存関係)。このアプリがデプロイされている IIS アプリ プールが 1 時間に 1 回 (数分かかるか、または数分かかります) リサイクルされることに気付き始めました。 ）。

私のアプリケーション ログには、何らかの問題を示すものは何もありません。Telegraf を使用してメトリクスを収集しますが、メモリ メトリクスの増加はまったく見られません。すべてのメトリクスが完全に正常に見え、アプリ プールがリサイクルされる限りです。

イベント ビューアーを見て、WAS ソースでログをフィルター処理すると、ID 5011 のイベントが表示されます。これは基本的に、IIS ワーカーがクラッシュしたことを意味します。

そこで、DebugDiag を使用して、自分のボックスにアプリを展開したローカル ボックスで実行しました (ローカルで問題を再現できます)。しばらく実行し、最終的にイベント ビューアーで同じイベントを取得しました。DebugDiag からのクラッシュ分析ログを調べたところ、多数の例外がログに記録されているかどうかがわかりましたが、クラッシュの直前に具体的なものは何もありませんでした。

現時点では、クラッシュの原因を突き止めるために他に何ができるか完全にはわかりません。そのため、透明性を高めるためにできることについて、さらに多くの提案があることを願っています。

私が考えているのは、依存関係の 1 つとアップグレードされたパッケージの一部との非互換性があり、例外がスローされ、何も処理されず、IIS ワーカーがクラッシュすることです。

すべての API エンドポイント機能に問題がなく、メモリが増加しておらず、CPU に問題がない限り、私のアプリケーションは完全に正常に動作しています。したがって、私が知る限り、クラッシュまで問題はありません。

クラッシュの原因を見つけたり、それを処理したりするためのトリックを誰かが知っているかどうか疑問に思って、この例外がワーカーをエスケープしてクラッシュするのを防ぎます。