デバッガー拡張」という機能があり、デバッガからCLRの状態を追いかけることができる。Frameworkのアプリケーションをデバッグすることができる。今回は、.NETアプリが異常終了したときにその状態を調べるという方法について。この役に立たないダイアログも、価値のあるものになるはず。WinDbgをインストールする今回はWinDbgを使うことにするので、WinDbgをインストールする。SDKをインストールすればついてくる。途中でコンポーネント選択の画面があるので、デバッガのみ選べば、他のコンポーネントをインストールしないことも可能。自動デバッガの設定をする上の「役に立たないダイアログ」の「プログラムをデバッグします」で起動するプログラムを変更する。NT\CurrentVersion\AeDebug」にある「Debugger」文字列値を追加/変更し、以下のようにする。-gx64版Windowsの場合は、SOS拡張を利用するには、実行するアプリケーションと同じアーキテクチャのwindbg.exeを使う必要があるので、上記のキーはx64版のwindbg.exeに向ける。NT\CurrentVersion\AeDebug」の「Debugger」文字列値をx86版windbg.exeに向けておく。SDKでWinDbgをデフォルト設定でインストールした場合)に使えるregファイルを置いておいた。Studioが使えなくなる)。v0.1.1には、「存在しないエディタが設定されていると、異常終了する」というバグがあるので、これを例にする。ポイントとなりそうな部分は勝手に太字にしてある。デバッガー拡張)」を見てコマンドを選ぶことになる。Launcherの「Settings」ボタンをクリックし、「Editor」テキストボックスに存在しないパスを入力する。その後、適当なmsbuildファイルを開き、「Edit」ボタンを押すと、異常終了し、上の役に立たないダイアログが出てくるので、「プログラムをデバッグします」をクリックすると、WinDbgが立ちあがる。ワークスペースを保存するか聞かれるので、Noを選ぶと、以下の画面になる。SOS拡張のロード上記の状態になったら以下の通り入力する。clrこれは「clr.dllの横にあるsos.dllをロードする」という意味。今回のケースではすでにclr.dllがロードされているので、特にメッセージなく終了するはず。Frameworkの2.0/3.xの場合「clr」は「mscorwks」とする。gで進めたあと「.loadby~」を行うか、「.load」で直接DLLの場所を指定してもOK(この場合、.NETのバージョンやアーキテクチャに注意する)。C:\Windows\Microsoft.NET\Framework64\v4.0.30319\SOS.dllこれで、SOS拡張がロードされた。(!PrintException)を実行する。指定されたファイルが見つかりません。80004005これでもう「System.Diagnostics.Process.StartWithShellExecuteEx」を呼んだ結果「System.ComponentModel.Win32Exception」が発生し「指定されたファイルが見つかりません。」というメッセージが出ていることがわかった。Launcherにおいて「System.Windows.Controls.Button.OnClick」から「System.Diagnostics.Process.Start」を呼ぶところなんて限られてくるので、もうわかったも同然なのだが、もう少し調べてみる。スタックのオブジェクトを一覧する(!dso)今回の場合「InnerException」がnoneなので、そこは調べられない。(!DumpStackObjects)で、スタックのオブジェクトを一覧できるので、表示してみる。「System.Diagnostics.ProcessStartInfo」オブジェクトを見ればもうすこしわかりそうなので、表示してみることにする。(!DumpObj)コマンドを使う。引数には、先程の「System.Diagnostics.ProcessStartInfo」のオブジェクトアドレスを指定する。environmentVariables「fileName」が使えそうなので、さらに表示してみる。<<これで、「C:\Windows\invalid-notepad.exe」という文字列がfileNameに入っていることがわかった。これでは実行できそうもない。---と、このような感じで、異常終了時の例外情報を調べるくらいならわりと簡単にできる。.NETプログラマなら覚えておくのがおすすめ。本当は、AppDomainの中を旅するだけの機能もついているのだけど、それはまた機会があれば。