3
私はWaitForDebugEvent() APIを使用して、サードパーティのアプリケーションをデバッグする際にデバッグイベントを処理しています。非常に頻繁に私はCLRによって投げられたアクセス違反をキャッチします（Debianはいくつかの.NETライブラリを使用しています）。私は後でWinDbgを使ってミニダンプを分析します。 WaitForDebugEvent()が返された直後に、CLRからのそのような例外を検出できますか？ここでCLRによってスローされた例外を検出する方法は？
は、キャッチした例外の詳細については、以下のとおりです。
EXCEPTION_RECORD: (.exr -1)
ExceptionAddress: 000007fef7e870eb (clr!EEFileLoadException::Throw+0x00000000000001ac)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 0000000000000000
Parameter[1]: 000000000000007d
Attempt to read from address 000000000000007d
非常にはっきりしていますが、誰かが前に言ったように、SOはずっと前に地獄になってしまっています。今日では、それは最初の場所で怒って開始するのに十分な評判が高い人々によって導かれた激しいコンテストのようなものです。 – kytodrk
さて、私は元々あなたの質問をアップアップしました。なぜなら、それは明らかで、潜在的に興味深いことに同意したからです。この編集により私はもっと混乱してしまいます。 WaitForDebugEventを使用すると、CLRによってスローされた例外が表示されず、これらの例外の通知を受け取る方法を尋ねていたと言っていると思いました。私には有効な質問のようです。では、編集した例外の詳細はどこから来たのですか？実際の問題は何ですか？用語の不正確な使用は役に立ちません。例外を「キャッチ」すると、例外ハンドラを意味し、TRUEを返すWaitForDebugEventではなく、 –
がクリアされます。 OK - あなたはclr.dllでそのExceptionAddressを見ることができます - これは "CLRによってスローされた"という意味ですか？どのような問題？ – RbMm