私たちのアプリケーションは未処理の例外をスローしています。DW20.exe は、次のテスト ケースのようにこれらをログに記録します。
EventType clr20r3, P1 clr20r3.exe, P2 1.0.0.0, P3 4af175d6, P4 clr20r3, P5 1.0.0.0, P6 4af175d6, P7 1, P8 a, P9 system.applicationexception, P10 NIL.
P9 は例外の名前です。例外名が 32 文字を超える場合、DW20.exe は名前をハッシュします (おそらくハッシュをエンコードします)。たとえば、例外「LongExceptionWithNameThatIsOver32」は次のように記録されます。
EventType clr20r3, P1 aspnet_wp.exe, P2 2.0.50727.3082, P3 492b8702, P4 app_web_bmcy0pha, P5 0.0.0.0, P6 4af86274, P7 59, P8 5, P9 3e3rjg2ow1fkknn0eqptakfytpvxew1k, P10 NIL.
ご覧のとおり、P9 はもはや例外名ではなく、名前のハッシュです。
アプリケーションで一度に 1 つずつ例外をスローすることもできますが、ハッシュを取得する代わりに、例外名をユーティリティ プログラムにフィードすることをお勧めします。DW20.exe がハッシュを行うプログラムであると確信しています (.NET ランタイムではありません)。すべての例外を処理して対応するハッシュ/エンコードを生成するユーティリティを構築できるように、dw20.exe が使用しているハッシュ/エンコード アルゴリズムを知りたいです。
テスト プログラムに windbg をアタッチしようとしましたが、dw20.exe が呼び出されません。Microsoftへの送信に関するダイアログボックスを表示するときにwindbgをdw20.exeに接続しようとしましたが、それまでにすでに例外が記録されています。windbg.exe の制御下で dw20.exe を起動できません。これは、何が使用されているかを調べる 1 つの方法です。
JR