問題タブ [postmortem-debugging]

Windows サービスがクラッシュしたときに、そのサービスのフル メモリ ダンプを作成することはできますか? 明らかに、失敗したプロセスのメモリ ダンプを収集できるよく知られている事後分析デバッガーがあります。しかし、Windows サービスの問題は、ユーザー コンテキストではなく、システム コンテキスト内で実行されていることです。誰でも私を助けることができますか？

今まで、WinDbgで試しました：

• WinDbg -I を実行して、WinDbg をデフォルトの事後分析デバッガーとして設定しました。
• レジストリの両方の場所 (HKLM\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\AeDebug と HKLM\SOFTWARE\Wow6432Node\Microsoft\WindowsNT\CurrentVersion\AeDebug) に、Auto と Debugger の 2 つのエントリが存在することを確認しました。
• デバッガーのエントリを "Path\WinDbg.exe" -p %ld –c ".dump /ma /u D:\CrashDump.dmp" -e %ld –g に変更して、起動時に自動的にメモリ ダンプを書き込むように WinDbg を構成しました。
• 管理者権限の有無にかかわらず、WinDbg がメモリ ダンプ ファイルのターゲットの場所に対する権限を持っていることを確認しました。

しかし、うまくいきません。:(

起動後に意図的にクラッシュする通常のユーザー モード アプリケーションを作成すると、WinDbg がポップアップし、.dmp ファイルがターゲットの場所に自動的に書き込まれます。しかし、私のサービスがクラッシュしても、クラッシュしません。タスク マネージャー内で、サービスのプロセスがクラッシュした後に WinDbg が開始されることを確認できますが、どちらもダンプ ファイルなしでリストに残ります。

sが原因で時折クラッシュする大規模な ASP.NET アプリケーションがありますStackOverflowException。これらは .NET によって非常にエレガントに処理されないため、通常の例外ログとスタック トレースを使用せずに、事後分析デバッグに縮小されます。問題が発生している場所を見つけたら、通常は簡単に修正できます。難しいのは、コードベースのどこでエラーが発生したかを特定することです。

クラッシュ後に取得したプロセス ダンプ ファイルは、この作業に大いに役立つように思われますが、これまでのところ、最適な使用方法を見つけることができませんでした。Visual Studio を使用してプロセスを (非常に、非常に、ゆっくりと) 「デバッグ」できますが、これは基本的に MSFT シンボルをロードするのに永遠に時間がかかり、アプリケーション DLL のシンボルをロードしません (したがって、呼び出しスタック)。

次のような簡単な方法が必要なようです。

• クラッシュ ダンプ ファイル
• マネージド アプリケーション DLL/PDB のセット

完全なマネージド コール スタックへ。誰でも（VS、WinDbg、またはその他のツールを使用して）これを行うために説明（またはチュートリアルを指す）できますか？

少なくとも管理対象アプリの終了を延期し (数十ミリ秒)、共有フラグを設定して他のスレッドに正常に終了する機会を与える方法はありますか (SO スレッド自体は明らかにそれ以上何も実行しません)。これに JIT デバッガーまたは CLR ホスティングを使用することを考えています。

なぜ私は何か間違ったことをしたいのですか?:

あまり詳しく説明しなくても、この類推を想像してみてください。あなたはカジノでルーレットに賭けていて、突然ルーレットが信頼できない偽物であることがわかりました。したがって、すぐにカジノを離れたいと思うかもしれませんが、最初にテーブルからベットを回収したいと思うでしょう。残念ながら、非常に厳しいパフォーマンス要件があるため、これに別のプロセスを利用することはできません。

試してみましたがうまくいきませんでした：

StackOverflowException (および MSDN の矛盾する情報) に対する .NET の動作については、SO で何度か議論されています。

HandleProcessCorruptedStateExceptionsAttribute (たとえば、appdomain の未処理の例外ハンドラー) が機能しない

ExecuteCodeWithGuaranteedCleanupが機能しない

legacyUnhandledExceptionPolicyが機能しない

StackOverflowExceptions を処理する他の試みはほとんどないかもしれませんが、Hans Passant によるこの素晴らしい回答で言及されているように、CLR がプロセス全体を終了させることは明らかです。

試してみることを検討してください：

• JIT デバッガー - 例外を凍結した状態でスレッドを残し、いくつかの共有フラグを設定し (ピン留めされた場所にある可能性が高い)、短時間他のスレッドを解凍します。
• CLR のホスティングと未処理の例外ポリシーの設定

他に何か考えはありますか？または、これら 2 つの方法での経験 (成功/失敗) はありますか?

ニワトリが先か卵が先かの問題です。

クライアント マシンでのアプリケーションの起動時に TypeInitializerException でクラッシュするアプリケーションがありますが、失敗することもあります。

procdump を使用してメモリ ダンプを収集することを考えていましたが、プロセスにアタッチして例外を待機するには、インスタンスが実行されている必要があります。

アプリケーションを起動しないと procdump を添付できず、起動時にアプリケーションがクラッシュします。

WinDbg 内からアプリケーションを起動してみることができますが、常に例外が発生するとは限らないため、それが役立つかどうかはわかりません。

アイデアや提案はありますか？

このアプリケーションは、.NET Framework 4.5 を対象として作成され、Windows Server 2008 R2 (最新の更新プログラムを適用) で実行されています。これまでのところ、これを自分のマシンでローカルに再現することはできませんでした。