文書化された検索順序にリストされていない場所から DLL をロードするプロセスがあります (以下にリンクされているドキュメント)。理由を知りたいです。
ここに私のセットアップの説明があります：
- a.dll と b.dll を含む「c:\foo」フォルダがあります。
- c:\foo にも Python スクリプトが保存されています。
- Python スクリプトは LoadLibrary('c:/foo/a.dll') を実行します (ctypes 経由)
- a.dll は、b.dll のインポート ライブラリに対してリンクされます (つまり、暗黙的なリンクを使用します)。
- たとえば、c: の現在のディレクトリで python スクリプトを実行します。それは何でもかまいません。
- b.dll は、検索パス上にないにもかかわらず、c:\foo から読み込まれます。
- プロセス モニターのトレースを見ると、文書化されているすべての検索パスが最初に試行され、すべて失敗したことがわかります。次に、python プロセスが「C:\WINDOWS\assembly\GAC\Microsoft.VC80.CRT.mui\8.0.50727.4053_en-US_1fc8b3b9a1e18e3b\Microsoft.VC80.CRT.mui.DLL」を開こうとして失敗し、c: を開きました。 \foo\b.dll。
そのため、ドキュメントにはそうあるべきだとは書かれていませんが、a.dll のディレクトリで b.dll が検索されているようです。また、これは狂っているシステム パスを調べた後に発生します。誰でもこれに光を当てることができますか？
a.dll も使用する MatLab スクリプトでも同じことが起こります。
Windows XP SP 3 を実行しています。
この MSDN の記事では、既定の検索順序について説明しています。私は引用します：
- lpFileName で指定されたディレクトリ。
- システム ディレクトリ。GetSystemDirectory 関数を使用して、このディレクトリのパスを取得します。
- 16 ビット システム ディレクトリ。このディレクトリのパスを取得する機能はありませんが、検索されます。
- Windows ディレクトリ。GetWindowsDirectory 関数を使用して、このディレクトリのパスを取得します。
- 現在のディレクトリ。
- PATH 環境変数にリストされているディレクトリー。これには、App Paths レジストリ キーで指定されたアプリケーションごとのパスは含まれないことに注意してください。DLL 検索パスを計算する場合、App Paths キーは使用されません。