C# で複数のアプリケーション用のログ サービスを設計しました。パフォーマンスの節約を考えると、すべてのログは最初にバッファに保存し、バッファがいっぱいになったらログ ファイルに書き込む必要があります。ただし、一部の拡張カード (PCI / PCI-e) が BSoD の原因となっており、私の管理外です。BSoD が発生するとバッファ内のログは失われますが、それらを保持する方法を見つけたいと考えています。
ソフトウェアがクラッシュしたときにデータをダンプする方法について議論している記事をいくつか見つけました。ただし、ミニダンプは自分ですべてをダンプする必要があり、パフォーマンスの問題が発生すると思います。他の記事(A) (B)は、単一のアプリケーションのクラッシュにのみ適しています。
BSoD が発生した場合でもログを保存するための提案はありますか?
編集:データの損失を最小限に抑えるための提案がある場合も歓迎します。
C# アプリケーションのバッファーはパフォーマンス上の理由からディスクに書き込まれないため、残りの場所はメモリ (RAM) だけです。クラッシュの瞬間に Windows がメモリをどのように管理しているかがわからないため、次の 2 つのケースを考慮する必要があります。a) ログが実際に RAM にある場合と、b) RAM がディスク (ページ ファイル) にスワップされている場合です。BSoD のすべての RAM にアクセスするには、カーネル ミニダンプの代わりにフル メモリ ダンプを作成するように Windows を構成する必要があります。
ブルー スクリーンが表示されると、オペレーティング システムは、ほとんどのカーネル ドライバーでさえ、ほとんどすべてに依存しなくなります。唯一の試行は、物理 RAM の内容をディスクに書き込むことです。さらに、有効な NTFS データ構造に依存することさえできないため、認識している連続したディスク領域の唯一の場所であるページ ファイルに書き込みます。これが、ページ ファイルが少なくとも物理 RAM といくつかのメタデータと同じ大きさである必要がある理由でもあります。そうしないと、情報を保持できません。
この時点で、ケース b) への回答をすでに提供できます。ログが実際にページ ファイルにスワップされた場合、ダンプによって上書きされる可能性があります。
バッファーが実際にワーキング セット (RAM) の一部である場合、その部分はカーネル ダンプに含まれます。カーネル ダンプから .NET アプリケーションをデバッグすることはほとんど不可能です。これは、.NET ヒープを分析する SOS コマンドがユーザー モードのフル メモリ ダンプに対してのみ機能するためです。他の方法 (特定の部分文字列など) でログ エントリを特定できる場合は、もちろん、カーネル ダンプで単純な文字列検索を実行できます。
全体として、あなたが達成しようとしていることは、XY-問題のように聞こえます。サービスをテストしたい場合は、関係のない問題のある PCI カードを取り外したり交換したり、別の PC でテストしたりしませんか? ブルー スクリーン ロギングがログ サービスの明示的な機能である場合は、これをリスクと見なし、サービスを作成する前に評価する必要があります。これはプロジェクト管理の問題であり、StackOverflow のトピックではありません。
残念ながら、@MobyDisk が言ったことを確認する必要があります。それは (ほとんど) 不可能であり、少なくとも信頼できません。