デバッグに役立つように、自分のアプリケーション (フレームワーク .NET 4.0 に対してコンパイルされた VB.NET) 自体のプロセス ダンプを書き込もうとしています。このために、Sysinternals の Procdump を使用しています。
開始するには、クリック イベントで次のコードを実行するだけです (したがって、コール スタックで何か認識できるはずです)。
Dim p As New Process
p.StartInfo.FileName = "C:\procdump.exe"
p.StartInfo.Arguments = "-accepteula -ma " & Process.GetCurrentProcess.Id
p.Start()
p.WaitForExit()
p.Dispose() ' Breakpoint
最後の行にもブレークポイントがあります。
ダンプを作成するには、VS 2010 内でアプリケーションをデバッグ モードで起動し、ボタンをクリックしてこのコードを実行します。ブレークポイントに到達すると、ダンプが書き込まれたことがわかります。この時点で、Visual Studio を使用して別のダンプ ファイルも作成します ([デバッグ] -> [ダンプを名前を付けて保存])。
これにより、Procdump.exe によって作成されたものと Visual Studio によって作成されたものの、ほぼ同じサイズ (400 メガバイト) の 2 つのダンプ ファイルが残ります。ビルドされたコードには何も触れずに、両方のダンプ ファイルを開き (ビルドされたコードを開いた状態で Ctrl+O を押します)、シンボル フォルダー オプションでデバッグ出力フォルダーを指定します。
ここで、Visual Studio によって作成されたダンプで [混合でデバッグ] をクリックすると、(メイン スレッドで) 認識可能なメソッド名を含むコール スタックが取得され、デバッガーはそれをソース コード内のブレークポイントのある位置に適切に配置します。だった。
ただし、Procdump によって作成されたダンプで [混合でデバッグ] をクリックすると、(メイン スレッドの) コール スタックには clr.dll!6cb34e46()、KERNELBASE.dll!75106a8e() と ntdll.dll! のようなものしか含まれません。上部に 76f07094() があります。認識可能なコードはなく、時計に関連するものもありません。
何故ですか？ 実際、私はこれら 2 つのダンプがほぼ等しいことを期待していました (数行のコードが異なるだけです)。 [アタッチされているデバッガーと関係があります。以下の編集を参照してください。]
どちらの場合も、シンボルが正しく読み込まれたことに注意してください。Debug->Windows->Modules で取得したリストは、両方のダンプに同じシンボルがロードされることを示しています。さらに、両方のダンプでバックグラウンド スレッドに切り替えると、両方のダンプでこれらの (変数の値などを含む) の正しいコール スタックが取得されます。
編集
デバッガーを接続せずにアプリケーションを実行すると、予想されるプロセス ダンプが得られることに気付きました (つまり、Visual Studio によってキャプチャされたものと同じですが、1 行ずれています)。問題が解決しました。しかし、デバッガーを接続した状態でなぜその結果が得られなかったのかについては、まだ興味があります。