このアプリケーションには、ネストされたディレクトリに DLL の形式でいくつかのアドオンがあります。ログを取得するバックグラウンドで実行されている DbgView のインスタンスを使用してテストを実行しています。問題は、ビルドを構築したコンピューターとは別のコンピューターでテストを実行することです。これにより、PE ヘッダー (Dumpbin ツールを介して抽出された) のデバッグ ディレクトリ エントリがほとんど無効になります。
そのようなシンボル サーバーはありません。ただし、すべての PDB ファイルは、デバッグ ビルドのバイナリの隣に適切な名前で配置されているため、問題なく検出されることを期待していました。
アドオンは LoadLibrary Windows 関数によって読み込まれ、次に SymLoadModule64 関数を使用してシンボル テーブルが読み込まれます。戻り値によると正しいですが、SymGetModuleInfo64 を使用して実際にロードされた PDB を確認すると、実際には何も表示されません。これは、アプリケーションのこの部分を修正することになった元の問題からも明らかです。つまり、前述のデバッグ ログのコール スタック、より正確には、アドオンに対応する部分がめちゃくちゃになっているということです。
関数のさまざまなバージョンを試し、DbgHelp ライブラリのバージョンも確認しましたが、役に立ちませんでした。
VS からのアタッチは、VS が実際に PDB を見つけられることを示していますが、シンボルの読み込みメカニズムと出力ウィンドウのログは依然として問題のある動作を示しています。VSが修正できるのは、混乱したコールスタックだけです。
DbgHelp のシンボルの読み込みは、アプリケーションのルート ディレクトリを「SymSearchPath」として、DEFERRED_LOAD を有効にして初期化されます。後者は削除する必要があり、前者はアドオンのディレクトリを含めるように設定されています。別の解決策は、PDB ファイルをこのルート ディレクトリに移動することでした。
MSDN の SymInitializeのリファレンスによると、「SymSearchPath」は PDB ファイルを再帰的に検索しますが、実際にはそうではありません。もう 1 つのことは、Web を閲覧して PDB ファイルを見つける方法を確認するたびに、バイナリのロード元のディレクトリで PDB ファイルが検索されるという行の 1 番目または 2 番目として読み取られますが、上で説明しましたが、これもそのようには起こりません。
全体として、問題は解決したように見えますが、ここには多くの混乱があります。
だから..
1.誰かがPDBファイルがロードされる真の方法を知っていれば、それは非常に啓発的です。.. ?
2. DbgHelp は根本的にバグがありますか?
3. MSDN でそう言われているのに、なぜ「SymSearchPath」は再帰的に検索されないのですか?
また、他に追加するものがあれば、それも大歓迎です。
このような長い投稿を読んでくれてありがとう。