LoadLibraryEx忽略完全歸檔的路徑名？

從我讀的MSDN documentation，我認爲（如果該基名的dll是尚未加載）傳遞完全限定的絕對文件名到LoadLibraryExW只會查看該路徑。LoadLibraryEx忽略完全歸檔的路徑名？

E.g. （請注意，這是正確的CSIDL_SYSTEM的路徑，如果有差別），如果該文件不存在該位置

LoadLibraryExW (L"C:\\Windows\\System32\\foobar.dll", LOAD_LIBRARY_AS_DATAFILE);

應該失敗。但是我得到了一些有趣的結果，這讓我認爲它取得了基本名稱並將它應用於Windows 8.1上的PATH。並在其他地方找到具有相同名稱的文件。

此外，如果我使用LOAD_LIBRARY_AS_DATAFILE它阻止我發現它實際上找到它的位置。

這個功能是什麼真的在這方面做了什麼，並且它隨操作系統版本而變化嗎？

（順便說一句，我知道LOAD_LIBRARY_SEARCH_SYSTEM32，但這並不能在所有操作系統版本存在的。我想在任何運行早在XP）。

這是因爲我覺得特別混亂，使用絕對路徑是一個有效的修補程序，我以前看到它通過PATH找到不正確的文件，作爲LOAD_LIBRARY_SEARCH_SYSTEM32的便攜式替代品。所以也許它會因操作系統或其他一些神奇的變化而改變行爲。

來源

2016-02-29 JDługosz

您需要顯示代碼並提供完整詳細的測試用例。尤其要注意，您鏈接的文檔中提到的適用的「LOAD_」標誌。 – dxiv

您可以使用Process Monitor（可從MS網站獲得）來確認文件是否真的從其他地方加載。一個想法：你記得在路徑中使用反斜槓，而不是正斜槓，對吧？ –

我認爲完全指定的DLL路徑將來自另一個實際位置的情況是涉及Wow64重定向的情況。如果您的應用程序是運行在Win64操作系統上的32位應用程序，默認情況下，System32的文件訪問權限將被重定向到SysWow64。見https://msdn.microsoft.com/en-us/library/windows/desktop/aa384187.aspx也許這就是發生在你身上的事情？將路徑更改爲System32以外的其他路徑，我認爲您會看到LoadLibraryEx（）函數失敗。 –

如果已加載該名稱的DLL，Windows將忽略該路徑。

因此，如果有一個foobar.dll已經從其他路徑加載過程中，那麼即使您指定了完整的絕對路徑到不同的foobar.dll，它也會返回第一個句柄，並將引用計數。

編輯：發現的documentation for this behavior：

如果用相同的模塊名稱的DLL已加載到內存，系統僅檢查重定向和清單解決所加載的DLL之前，無論它所在的目錄。系統不搜索DLL。

來源

2016-03-01 00:40:23

對不起，有問題的DLL尚未加載（與觀察到的行爲）。我知道這是引用現有加載文件的情況。我會澄清這個問題。 –

也許您可以編輯問題以顯示調試器中輸出窗口中的所有「模塊加載」消息。這應該告訴我們究竟發生了什麼（包括是否加載了另一個同名的DLL）。 –

我一直在使用Process Monitor是用作LoadLibraryEx參數完全合格的文件名確實會導致只路徑進行檢查（即，當它需要加載一個文件，因爲沒有觀察到該名稱的DLL已經加載）。這在32位進程中被觀察到。

對於System32目錄，在64位操作系統上，作爲C：\ Windows \ System32作爲參數給出的參數在ProcMon中顯示爲C：\ Windows \ SysWOW64。

這在

視窗XP SP3觀察到，32位（古怪：如果DLL不存在，QueryOpen與相同的路徑稱爲兩次）
Windows 7中，32位
的Windows 10，64位

一個需要注意的是，即使命名的DLL從指定目錄加載了絕對路徑，其依賴的DLL加載與PATH的正常搜索。當使用LOAD_LIBRARY_AS_DATAFILE時，這不是問題。

來源

2016-03-02 05:38:20

LoadLibraryEx忽略完全歸檔的路徑名？

回答

相關問題