問題タブ [windows-error-reporting]

Visual Studio 2008 で作成された C# WinForms アプリケーションの Windows 7 64 ビットを実行しているターゲット マシンで発生したエラーを追跡しようとしています。イベント ビューアーからの Windows エラー報告の出力だけを追跡する必要があります。ここで多くの役立つ情報を見つけました: http://www.codeilove.com/2012/09/debugging-using-windows-error-reporting.html。

リンクから、P7、P8、および P9 が最も重要であり、06000c43 を探すことで、ILDASM を使用して「c43」のメソッド定義を見つけることができるはずです。C:\Windows\Microsoft.NET\Framework\v2.0.50727\mscorlib.dll の System.Number で次の内容を見つけます。

この情報によると、System.Number.ParseUInt64 で System.FormatException が発生していますね。Visual Studio でプロジェクトを検索しましたが、コードがこの関数を呼び出しているインスタンスが見つかりません。ここからどこへ行けばいいですか？

未処理の例外をファイルに記録する Application.ThreadException のトップレベルの例外ハンドラーがあります。この場合、アプリケーション クラッシュが発生し、ログ ファイルには何も記録されません。この例外が私の UI 以外のスレッドで発生していると想定しても安全ですか?

X ボタンをクリックしてプログラム (MYAPP など) を閉じると、次のようなダイアログが表示されました。

MYAPP が機能しなくなった

Windows はオンラインで問題の解決策を確認できます。」

しかし、実際にはアプリケーションはすでに終了していました。

エラー情報:

Windows は、プログラムが「動作を停止」したかどうかをどのように検出しますか? アプリケーションが例外またはデッドロックをスローしたことを示していますか?

完全なクラッシュ ダンプを作成する API が利用できるかどうかを知りたいです。

現在、私はMiniDumpWithFullMemory でMiniDumpWriteDump () API を使用しています。しかし、作成されたダンプから分析する情報があまり得られません。

ユーザー セッションを追跡するための WPF サービスを作成しましたが、ユーザー セッションを追跡しながら、サービス クラッシュのイベントも追跡したいと考えています。そのために、Windowsイベントログをチェックしてエラーを特定しています。しかし、私は混乱しています。セッション変更の処理に失敗したことを示すエラーが表示されていました! それはサービスクラッシュですか?? サービスクラッシュの特定の例外コードはありますか/システムクラッシュを特定するための関連記事/ポイントの提案を手伝ってくれる人はいますか?

Windows エラー報告には、特定のハングのダンプ ファイルがいくつかあります。ダンプを開くと、醜いメッセージが表示されます

正しいダンプを収集してアップロードするように WER を構成するにはどうすればよいですか?

PS: この特定のクラッシュは、Windows 7 x64 でのみ発生します。この OS の wow64 エミュレーターには何か特別なものがありますか?

アプリケーションからプロセスを開始して監視します。クラッシュまたはハングアップする可能性があります。

監視アプリケーションはこれに備えており、これを処理できます。

しかし、クラッシュ ウィンドウでは、アプリケーション クラッシュ ダイアログが表示されます。この時点で、クラッシュしたプロセスはまだプロセス リストにあります。ただし、監視アプリによってプロセスが終了される場合 ( でタイムアウトした後)、ダイアログは消えませんTerminateProcess。

WerAddExcludedApplicationと を使用して、このアプリケーションの Windows エラー報告を無効にしようとしましたWerRemoveExcludedApplicationが、オンラインで解決策を検索するオプションが削除されるだけです。

また、WER を完全に無効にしたくもありません。

特定の実行可能ファイルに対してこのダイアログをプログラムで無効にする別の方法はありますか (常に同じであるとは限りません)。

Windows 64 ビット PC で作業しています。私のアプリケーションは、同じ名前の Proc.exe を持つ 32 ビット プロセスの 10 以上のインスタンスを起動します。これらのインスタンスは非常に近い時間に起動されます。特定のシナリオでは、クラッシュも非常に近い時間に発生します。WER を使用して、これらのクラッシュのクラッシュ ダンプを収集しようとしています。MSDN の記事「ユーザー モード ダンプの収集」で説明されているように、レジストリ キー HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\Proc.exe を使用します。フル ダンプ (DumpType=2) を使用します。ターゲット ダンプ フォルダーで、PID 番号が異なる名前のダンプ ファイルを多数取得します: Proc.exe.1836.dmp、Proc.exe.5428.dmp など。

問題: 生成されたダンプ ファイルの総数は、DumpCount の値と必ずしも正確に一致するとは限りません。多くの場合、より多くのファイルがあり、実際の数は実行ごとに異なります。DumpCount=1 の場合は最大 5 個、DumpCount=3 の場合は最大 8 個のファイルが表示されました。プロセスごとの設定ではなく、グローバルな LocalDumps 設定 (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps) で作業しようとしましたが、結果は似ています。

ディスクの空き容量が非常に限られているため、生成されるダンプ ファイルの数を制御することが重要です。

それとも、今報告したのは Windows のバグですか?