LoadLibraryExA-Funktion (libloaderapi.h)
Lädt das angegebene Modul in den Adressraum des aufrufenden Prozesses. Das angegebene Modul kann dazu führen, dass andere Module geladen werden.
Syntax
HMODULE LoadLibraryExA(
[in] LPCSTR lpLibFileName,
HANDLE hFile,
[in] DWORD dwFlags
);
Parameter
[in] lpLibFileName
Eine Zeichenfolge, die den Dateinamen des zu ladenden Moduls angibt. Dieser Name bezieht sich nicht auf den Namen, der in einem Bibliotheksmodul selbst gespeichert ist, wie durch das schlüsselwort LIBRARY in der Moduldefinitionsdatei (.def) angegeben.
Das Modul kann ein Bibliotheksmodul (eine .dll Datei) oder ein ausführbares Modul (eine .exe Datei) sein. Wenn es sich bei dem angegebenen Modul um ein ausführbares Modul handelt, werden statische Importe nicht geladen; Stattdessen wird das Modul geladen, als ob DONT_RESOLVE_DLL_REFERENCES angegeben wurde. Weitere Informationen finden Sie im dwFlags Parameter.
Wenn die Zeichenfolge einen Modulnamen ohne Pfad angibt und die Dateinamenerweiterung weggelassen wird, fügt die Funktion die Standardbibliothekserweiterung ".DLL" an den Modulnamen an. Um zu verhindern, dass die Funktion ".DLL" an den Modulnamen anfügen kann, fügen Sie ein nachfolgendes Punktzeichen (.) in die Modulnamenzeichenfolge ein.
Wenn die Zeichenfolge einen vollqualifizierten Pfad angibt, durchsucht die Funktion nur diesen Pfad für das Modul. Achten Sie beim Angeben eines Pfads darauf, dass Umgekehrte Schrägstriche (\) und keine Schrägstriche (/) verwendet werden. Weitere Informationen zu Pfaden finden Sie unter Namensdateien, Pfade und Namespaces.
Wenn die Zeichenfolge einen Modulnamen ohne Pfad angibt und mehrere geladene Module denselben Basisnamen und dieselbe Erweiterung aufweisen, gibt die Funktion ein Handle an das Modul zurück, das zuerst geladen wurde.
Wenn die Zeichenfolge einen Modulnamen ohne Pfad und ein Modul mit demselben Namen nicht bereits geladen wird oder wenn die Zeichenfolge einen Modulnamen mit einem relativen Pfad angibt, sucht die Funktion nach dem angegebenen Modul. Die Funktion sucht auch nach Modulen, wenn das angegebene Modul geladen wird, sodass das System andere zugeordnete Module lädt (d. a., wenn das Modul Abhängigkeiten hat). Die durchsuchten Verzeichnisse und die Reihenfolge, in der sie durchsucht werden, hängen vom angegebenen Pfad und dem dwFlags Parameter ab. Weitere Informationen finden Sie in den Hinweisen.
Wenn die Funktion das Modul oder eine seiner Abhängigkeiten nicht finden kann, schlägt die Funktion fehl.
hFile
Dieser Parameter ist für die zukünftige Verwendung reserviert. Es muss NULL-sein.
[in] dwFlags
Die Aktion, die beim Laden des Moduls ausgeführt werden soll. Wenn keine Kennzeichnungen angegeben werden, ist das Verhalten dieser Funktion identisch mit dem der LoadLibrary-Funktion. Dieser Parameter kann einer der folgenden Werte sein:
| Wert | Bedeutung |
|---|---|
|
Wenn dieser Wert verwendet wird und das ausführbare Modul eine DLL ist, ruft das System keine DllMain- für die Prozess- und Threadinitialisierung und -beendigung auf. Außerdem lädt das System keine zusätzlichen ausführbaren Module, auf die vom angegebenen Modul verwiesen wird.
Hinweis Verwenden Sie diesen Wert nicht; sie wird nur aus Gründen der Abwärtskompatibilität bereitgestellt. Wenn Sie nur auf Daten oder Ressourcen in der DLL zugreifen möchten, verwenden Sie LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVE oder LOAD_LIBRARY_AS_IMAGE_RESOURCE oder beides. Laden Sie andernfalls die Bibliothek als DLL- oder ausführbares Modul mithilfe der LoadLibrary-Funktion.
|
|
Wenn dieser Wert verwendet wird, überprüft das System nicht AppLocker- Regeln oder wendet Richtlinien für Softwareeinschränkung für die DLL an. Diese Aktion gilt nur für die geladene DLL und nicht für ihre Abhängigkeiten. Dieser Wert wird für die Verwendung in Setupprogrammen empfohlen, die extrahierte DLLs während der Installation ausführen müssen.
Windows Server 2008 R2 und Windows 7: Auf Systemen, auf denen KB2532445 installiert sind, muss der Aufrufer als "LocalSystem" oder "TrustedInstaller" ausgeführt werden; andernfalls ignoriert das System dieses Flag. Weitere Informationen finden Sie unter "Sie können AppLocker-Regeln umgehen, indem Sie ein Office-Makro auf einem Computer verwenden, auf dem Windows 7 oder Windows Server 2008 R2 ausgeführt wird" in der Help and Support Knowledge Base unter https://support.microsoft.com/kb/2532445. Windows Server 2008, Windows Vista, Windows Server 2003 und Windows XP: AppLocker wurde in Windows 7 und Windows Server 2008 R2 eingeführt. |
|
Wenn dieser Wert verwendet wird, ordnet das System die Datei dem virtuellen Adressraum des aufrufenden Prozesses zu, als wäre es eine Datendatei. Es wird nichts getan, um die zugeordnete Datei auszuführen oder vorzubereiten. Daher können Sie keine Funktionen wie GetModuleFileName-, GetModuleHandle- oder GetProcAddress- mit dieser DLL aufrufen. Die Verwendung dieses Werts bewirkt, dass schreibgeschützter Speicher schreibgeschützt ist, um eine Zugriffsverletzung auszuheben. Verwenden Sie dieses Flag, wenn Sie eine DLL nur laden möchten, um Nachrichten oder Ressourcen daraus zu extrahieren.
Dieser Wert kann mit LOAD_LIBRARY_AS_IMAGE_RESOURCEverwendet werden. Weitere Informationen finden Sie in den Hinweisen. |
|
Ähnlich wie LOAD_LIBRARY_AS_DATAFILE, mit der Ausnahme, dass die DLL-Datei mit exklusivem Schreibzugriff für den Aufrufvorgang geöffnet wird. Andere Prozesse können die DLL-Datei nicht für den Schreibzugriff öffnen, während sie verwendet wird. Die DLL kann jedoch weiterhin von anderen Prozessen geöffnet werden.
Dieser Wert kann mit LOAD_LIBRARY_AS_IMAGE_RESOURCEverwendet werden. Weitere Informationen finden Sie in den Hinweisen. Windows Server 2003 und Windows XP: Dieser Wert wird erst unter Windows Vista unterstützt. |
|
Wenn dieser Wert verwendet wird, ordnet das System die Datei dem virtuellen Adressraum des Prozesses als Bilddatei zu.
Das Ladeprogramm lädt jedoch nicht die statischen Importe oder führt die anderen üblichen Initialisierungsschritte aus. Verwenden Sie dieses Flag, wenn Sie eine DLL nur laden möchten, um Nachrichten oder Ressourcen daraus zu extrahieren.
Sofern die Anwendung nicht von der Datei mit dem Speicherlayout eines Bilds abhängt, sollte dieser Wert entweder mit LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVE oder LOAD_LIBRARY_AS_DATAFILEverwendet werden. Weitere Informationen finden Sie im Abschnitt "Hinweise". Windows Server 2003 und Windows XP: Dieser Wert wird erst unter Windows Vista unterstützt. |
|
Wenn dieser Wert verwendet wird, wird das Installationsverzeichnis der Anwendung nach der DLL und den zugehörigen Abhängigkeiten gesucht. Verzeichnisse im Standardmäßigen Suchpfad werden nicht durchsucht. Dieser Wert kann nicht mit LOAD_WITH_ALTERED_SEARCH_PATHkombiniert werden.
Windows 7, Windows Server 2008 R2, Windows Vista und Windows Server 2008: Dieser Wert erfordert, dass KB2533623 installiert werden. Windows Server 2003 und Windows XP: Dieser Wert wird nicht unterstützt. |
|
Dieser Wert ist eine Kombination aus LOAD_LIBRARY_SEARCH_APPLICATION_DIR, LOAD_LIBRARY_SEARCH_SYSTEM32und LOAD_LIBRARY_SEARCH_USER_DIRS. Verzeichnisse im Standardmäßigen Suchpfad werden nicht durchsucht. Dieser Wert kann nicht mit LOAD_WITH_ALTERED_SEARCH_PATHkombiniert werden.
Dieser Wert stellt die empfohlene maximale Anzahl von Verzeichnissen dar, die eine Anwendung in den DLL-Suchpfad aufnehmen soll. Windows 7, Windows Server 2008 R2, Windows Vista und Windows Server 2008: Dieser Wert erfordert, dass KB2533623 installiert werden. Windows Server 2003 und Windows XP: Dieser Wert wird nicht unterstützt. |
|
Wenn dieser Wert verwendet wird, wird das Verzeichnis, das die DLL enthält, vorübergehend am Anfang der Liste der Verzeichnisse hinzugefügt, die nach den Abhängigkeiten der DLL durchsucht werden. Verzeichnisse im Standardmäßigen Suchpfad werden nicht durchsucht.
Der parameter lpFileName muss einen vollqualifizierten Pfad angeben. Dieser Wert kann nicht mit LOAD_WITH_ALTERED_SEARCH_PATHkombiniert werden. Wenn Lib2.dll beispielsweise eine Abhängigkeit von C:\Dir1\Lib1.dll, loading Lib1.dll with this value causes the system to search for Lib2.dll nur in C:\Dir1 ist. Wenn Sie in C:\Dir1 und allen Verzeichnissen im DLL-Suchpfad nach Lib2.dll suchen möchten, kombinieren Sie diesen Wert mit LOAD_LIBRARY_SEARCH_DEFAULT_DIRS. Windows 7, Windows Server 2008 R2, Windows Vista und Windows Server 2008: Dieser Wert erfordert, dass KB2533623 installiert werden. Windows Server 2003 und Windows XP: Dieser Wert wird nicht unterstützt. |
|
Wenn dieser Wert verwendet wird, wird %windows%\system32 nach der DLL und den zugehörigen Abhängigkeiten gesucht.
Verzeichnisse im Standardmäßigen Suchpfad werden nicht durchsucht. Dieser Wert kann nicht mit LOAD_WITH_ALTERED_SEARCH_PATHkombiniert werden.
Windows 7, Windows Server 2008 R2, Windows Vista und Windows Server 2008: Dieser Wert erfordert, dass KB2533623 installiert werden. Windows Server 2003 und Windows XP: Dieser Wert wird nicht unterstützt. |
|
Wenn dieser Wert verwendet wird, werden Verzeichnisse, die mithilfe der AddDllDirectory hinzugefügt werden, oder die SetDllDirectory--Funktion nach der DLL und den zugehörigen Abhängigkeiten durchsucht. Wenn mehrere Verzeichnisse hinzugefügt wurden, wird die Reihenfolge, in der die Verzeichnisse durchsucht werden, nicht angegeben. Verzeichnisse im Standardmäßigen Suchpfad werden nicht durchsucht. Dieser Wert kann nicht mit LOAD_WITH_ALTERED_SEARCH_PATHkombiniert werden.
Windows 7, Windows Server 2008 R2, Windows Vista und Windows Server 2008: Dieser Wert erfordert, dass KB2533623 installiert werden. Windows Server 2003 und Windows XP: Dieser Wert wird nicht unterstützt. |
|
Wenn dieser Wert verwendet wird und lpFileName einen absoluten Pfad angibt, verwendet das System die alternative Dateisuchstrategie, die im Abschnitt "Hinweise" erläutert wird, um zugeordnete ausführbare Module zu finden, die das angegebene Modul zu laden verursacht. Wenn dieser Wert verwendet wird und lpFileName einen relativen Pfad angibt, ist das Verhalten nicht definiert.
Wenn dieser Wert nicht verwendet wird oder wenn lpFileName keinen Pfad angibt, verwendet das System die im Abschnitt "Hinweise" erläuterte Standardsuchstrategie, um zugeordnete ausführbare Module zu finden, die das angegebene Modul zu laden verursacht. Dieser Wert kann nicht mit einem LOAD_LIBRARY_SEARCH Flag kombiniert werden. |
|
Gibt an, dass die digitale Signatur des Binären Bilds zum Ladezeitpunkt überprüft werden muss.
Dieser Wert erfordert Windows 8.1, Windows 10 oder höher. |
|
Wenn dieser Wert verwendet wird, ist das Laden einer DLL für die Ausführung aus dem aktuellen Verzeichnis nur zulässig, wenn sie sich unter einem Verzeichnis in der Liste "Sicheres Laden" befindet. |
Rückgabewert
Wenn die Funktion erfolgreich ist, ist der Rückgabewert ein Handle für das geladene Modul.
Wenn die Funktion fehlschlägt, ist der Rückgabewert NULL-. Rufen Sie GetLastErrorauf, um erweiterte Fehlerinformationen zu erhalten.
Bemerkungen
Die LoadLibraryEx--Funktion ist der LoadLibrary-Funktion sehr ähnlich. Die Unterschiede bestehen aus einer Reihe optionaler Verhaltensweisen, die LoadLibraryEx- bietet:
- LoadLibraryEx- kann ein DLL-Modul laden, ohne die DllMain--Funktion der DLL aufzurufen.
- LoadLibraryEx- kann ein Modul auf eine Weise laden, die für den Fall optimiert ist, dass das Modul nie ausgeführt wird und das Modul so lädt, als wäre es eine Datendatei.
- LoadLibraryEx- können Module und die zugehörigen Module mithilfe von zwei Suchstrategien finden oder eine prozessspezifische Gruppe von Verzeichnissen durchsuchen.
Der aufrufende Prozess kann das von LoadLibraryEx zurückgegebene Handle verwenden, um das Modul in Aufrufen der GetProcAddress, FindResource-und LoadResource--Funktionen zu identifizieren.
Verwenden Sie die SetErrorMode--Funktion, um Fehlermeldungen zu aktivieren oder zu deaktivieren, die vom Ladeprogramm während der DLL-Ladevorgänge angezeigt werden.
Es ist nicht sicher, LoadLibraryEx- von DllMainaufzurufen. Weitere Informationen finden Sie im Abschnitt "Hinweise" in DllMain.
Visual C++: Der Visual C++-Compiler unterstützt eine Syntax, mit der Sie threadlokale Variablen deklarieren können: _declspec(Thread). Wenn Sie diese Syntax in einer DLL verwenden, können Sie die DLL nicht explizit mit LoadLibraryEx- in Versionen von Windows vor Windows Vista laden. Wenn Die DLL explizit geladen wird, müssen Sie die lokalen Threadspeicherfunktionen anstelle von _declspec(Thread)verwenden. Ein Beispiel finden Sie unter Verwenden des lokalen Threadspeichers in einer Dynamic Link Library.
Laden einer DLL als Datendatei oder Bildressource
Die werte LOAD_LIBRARY_AS_DATAFILE, LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVEund LOAD_LIBRARY_AS_IMAGE_RESOURCE wirken sich auf die Anzahl der einzelnen Prozesse und das Laden des angegebenen Moduls aus. Wenn eines dieser Werte für den dwFlags Parameter angegeben wird, überprüft das Ladeprogramm, ob das Modul bereits vom Prozess als ausführbare DLL geladen wurde. Wenn ja, bedeutet dies, dass das Modul bereits dem virtuellen Adressraum des aufrufenden Prozesses zugeordnet ist. In diesem Fall gibt LoadLibraryEx ein Handle an die DLL zurück und erhöht die DLL-Verweisanzahl. Wenn das DLL-Modul noch nicht als DLL geladen wurde, ordnet das System das Modul als Daten- oder Bilddatei und nicht als ausführbare DLL zu. In diesem Fall gibt LoadLibraryEx ein Handle an die geladenen Daten oder Bilddateien zurück, erhöht jedoch nicht die Verweisanzahl für das Modul und macht das Modul nicht für Funktionen wie CreateToolhelp32Snapshot oder EnumProcessModulessichtbar.Wenn LoadLibraryEx- zweimal für dieselbe Datei mit LOAD_LIBRARY_AS_DATAFILE, LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVEoder LOAD_LIBRARY_AS_IMAGE_RESOURCEaufgerufen wird, werden zwei separate Zuordnungen für die Datei erstellt.
Wenn der LOAD_LIBRARY_AS_IMAGE_RESOURCE-Wert verwendet wird, wird das Modul als Bild mit der Ausrichtungserweiterung für portable ausführbare Dateien (PORTABLE Executable, PE) geladen. Relative virtuelle Adressen (RVA) müssen nicht datenträgeradressen zugeordnet werden, sodass Ressourcen schneller aus dem Modul abgerufen werden können. Wenn Sie LOAD_LIBRARY_AS_IMAGE_RESOURCE angeben, werden andere Prozesse daran gehindert, das Modul während des Ladens zu ändern.
Sofern eine Anwendung nicht von bestimmten Bildzuordnungsmerkmalen abhängt, sollte der LOAD_LIBRARY_AS_IMAGE_RESOURCE Wert entweder mit LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVE oder LOAD_LIBRARY_AS_DATAFILEverwendet werden. Auf diese Weise kann das Ladeprogramm auswählen, ob das Modul als Bildressource oder als Datendatei geladen werden soll. Die Auswahl der Option, mit der das System Seiten effektiver freigeben kann. Ressourcenfunktionen wie FindResource- können eine der beiden Zuordnungen verwenden.
Um zu bestimmen, wie ein Modul geladen wurde, verwenden Sie eines der folgenden Makros, um das von LoadLibraryExzurückgegebene Handle zu testen.
#define LDR_IS_DATAFILE(handle) (((ULONG_PTR)(handle)) & (ULONG_PTR)1)
#define LDR_IS_IMAGEMAPPING(handle) (((ULONG_PTR)(handle)) & (ULONG_PTR)2)
#define LDR_IS_RESOURCE(handle) (LDR_IS_IMAGEMAPPING(handle) || LDR_IS_DATAFILE(handle))
In der folgenden Tabelle werden diese Makros beschrieben.
| Makro | Beschreibung |
|---|---|
| LDR_IS_DATAFILE(Handle) | Wenn dieses Makro TRUE-zurückgibt, wurde das Modul als Datendatei geladen (LOAD_LIBRARY_AS_DATAFILE oder LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVE). |
| LDR_IS_IMAGEMAPPING(Handle) | Wenn dieses Makro TRUEzurückgibt, wurde das Modul als Bilddatei (LOAD_LIBRARY_AS_IMAGE_RESOURCE) geladen. |
| LDR_IS_RESOURCE(Handle) | Wenn dieses Makro TRUE-zurückgibt, wurde das Modul entweder als Datendatei oder als Bilddatei geladen. |
Verwenden Sie die FreeLibrary--Funktion, um ein geladenes Modul freizulösen, unabhängig davon, ob das Modul geladen wurde, was dazu führte, dass die Referenzanzahl erhöht wurde. Wenn das Modul als Daten- oder Bilddatei geladen wurde, wird die Zuordnung zerstört, die Referenzanzahl wird jedoch nicht erhöht. Andernfalls wird die DLL-Verweisanzahl dekrementiert. Daher ist es sicher, FreeLibrary mit jedem Handle aufzurufen, der von LoadLibraryExzurückgegeben wird.
Suchen nach DLLs und Abhängigkeiten
Der Suchpfad ist der Satz von Verzeichnissen, die nach einer DLL gesucht werden. Die LoadLibraryEx--Funktion kann mithilfe eines standardmäßigen Suchpfads oder eines geänderten Suchpfads nach einer DLL suchen oder einen prozessspezifischen Suchpfad verwenden, der mit den funktionen SetDefaultDllDirectories und AddDllDirectory funktionen eingerichtet wurde. Eine Liste der Verzeichnisse und die Reihenfolge, in der sie durchsucht werden, finden Sie unter Dynamic-Link Bibliothekssuchreihenfolge.Die LoadLibraryEx--Funktion verwendet den standardmäßigen Suchpfad in den folgenden Fällen:
- Der Dateiname wird ohne Pfad angegeben, und der Basisdateiname stimmt nicht mit dem Basisdateinamen eines geladenen Moduls überein, und keines der LOAD_LIBRARY_SEARCH Flags werden verwendet.
- Es wird ein Pfad angegeben, LOAD_WITH_ALTERED_SEARCH_PATH wird jedoch nicht verwendet.
- Die Anwendung hat keinen standardmäßigen DLL-Suchpfad für den Prozess mit SetDefaultDllDirectoriesangegeben.
Wenn lpFileName einen relativen Pfad angibt, wird der gesamte relative Pfad an jedes Token im DLL-Suchpfad angefügt. Um ein Modul aus einem relativen Pfad zu laden, ohne einen anderen Pfad zu durchsuchen, verwenden Sie GetFullPathName-, um einen nichtrelativen Pfad abzurufen und LoadLibraryEx- mit dem nichtrelativen Pfad aufzurufen. Wenn das Modul als Datendatei geladen wird und der relative Pfad mit "." oder "." beginnt, wird der relative Pfad als absoluter Pfad behandelt.
Wenn lpFileName einen absoluten Pfad angibt und dwFlags- auf LOAD_WITH_ALTERED_SEARCH_PATHfestgelegt ist, verwendet LoadLibraryEx den geänderten Suchpfad. Das Verhalten ist nicht definiert, wenn LOAD_WITH_ALTERED_SEARCH_PATH Flag festgelegt wird, und lpFileName- einen relativen Pfad angibt.
Die SetDllDirectory--Funktion kann verwendet werden, um den Suchpfad zu ändern. Diese Lösung ist besser als SetCurrentDirectory oder hartcodieren Sie den vollständigen Pfad zur DLL. Beachten Sie jedoch, dass die Verwendung von SetDllDirectory den sicheren DLL-Suchmodus effektiv deaktiviert, während sich das angegebene Verzeichnis im Suchpfad befindet und nicht threadsicher ist. Wenn möglich, empfiehlt es sich, AddDllDirectory- zu verwenden, um einen Standardmäßigen Suchpfad für Prozesse zu ändern. Weitere Informationen finden Sie unter Dynamic-Link Bibliothekssuchreihenfolge.
Eine Anwendung kann die Verzeichnisse angeben, die nach einem einzelnen LoadLibraryEx- Aufruf mithilfe der LOAD_LIBRARY_SEARCH_* Flags gesucht werden sollen. Wenn mehrere LOAD_LIBRARY_SEARCH Flag angegeben sind, werden die Verzeichnisse in der folgenden Reihenfolge durchsucht:
- Das Verzeichnis, das die DLL (LOAD_LIBRARY_SEARCH_DLL_LOAD_DIR) enthält. Dieses Verzeichnis wird nur nach Abhängigkeiten der zu ladenden DLL durchsucht.
- Das Anwendungsverzeichnis (LOAD_LIBRARY_SEARCH_APPLICATION_DIR).
- Pfade, die explizit dem Anwendungssuchpfad mit der AddDllDirectory-Funktion (LOAD_LIBRARY_SEARCH_USER_DIRS) oder der SetDllDirectory-Funktion hinzugefügt wurden. Wenn mehrere Pfade hinzugefügt wurden, ist die Reihenfolge, in der die Pfade durchsucht werden, nicht angegeben.
- Das System32-Verzeichnis (LOAD_LIBRARY_SEARCH_SYSTEM32).
Windows 7, Windows Server 2008 R2, Windows Vista und Windows Server 2008: Die LOAD_LIBRARY_SEARCH_ Flags sind auf Systemen verfügbar, auf denen KB2533623 installiert sind. Um festzustellen, ob die Flags verfügbar sind, verwenden Sie GetProcAddress-, um die Adresse der AddDllDirectory-, RemoveDllDirectory-oder SetDefaultDllDirectories-Funktion abzurufen. Wenn GetProcAddress erfolgreich ist, können die LOAD_LIBRARY_SEARCH_ Flags mit LoadLibraryEx-verwendet werden.
Wenn die Anwendung die SetDefaultDllDirectories-Funktion verwendet hat, um einen DLL-Suchpfad für den Prozess einzurichten, und keines der LOAD_LIBRARY_SEARCH_* Flags verwendet wird, verwendet die LoadLibraryEx--Funktion den Prozess-DLL-Suchpfad anstelle des Standardmäßigen Suchpfads.
Wenn ein Pfad angegeben ist und der Anwendung eine Umleitungsdatei zugeordnet ist, sucht die LoadLibraryEx--Funktion nach dem Modul im Anwendungsverzeichnis. Wenn das Modul im Anwendungsverzeichnis vorhanden ist, LoadLibraryEx die Pfadspezifikation ignoriert und das Modul aus dem Anwendungsverzeichnis lädt. Wenn das Modul nicht im Anwendungsverzeichnis vorhanden ist, lädt die Funktion das Modul aus dem angegebenen Verzeichnis. Weitere Informationen finden Sie unter Dynamic Link Library Redirection.
Wenn Sie LoadLibraryEx- mit dem Namen einer Assembly ohne Pfadspezifikation aufrufen und die Assembly im systemkompatiblen Manifest aufgeführt wird, wird der Aufruf automatisch an die parallele Assembly umgeleitet.
Sicherheitsmerkungen
LOAD_LIBRARY_AS_DATAFILE verhindert nicht, dass andere Prozesse das Modul während des Ladens ändern. Da die Anwendung dadurch weniger sicher sein kann, sollten Sie LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVE anstelle von LOAD_LIBRARY_AS_DATAFILE verwenden, wenn Sie ein Modul als Datendatei laden, es sei denn, Sie müssen LOAD_LIBRARY_AS_DATAFILEverwenden. Wenn Sie LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVE angeben, werden andere Prozesse daran gehindert, das Modul während des Ladens zu ändern. Geben Sie LOAD_LIBRARY_AS_DATAFILE und LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVE nicht im gleichen Anruf an.Verwenden Sie die SearchPath--Funktion nicht, um einen Pfad zu einer DLL für einen nachfolgenden LoadLibraryEx-aufruf abzurufen. Die SearchPath-Funktion verwendet eine andere Suchreihenfolge als LoadLibraryEx und verwendet keinen abgesicherten Suchmodus, es sei denn, dies wird explizit durch Aufrufen SetSearchPathMode mit BASE_SEARCH_PATH_ENABLE_SAFE_SEARCHMODEaktiviert. Daher wird SearchPath- wahrscheinlich zuerst das aktuelle Arbeitsverzeichnis des Benutzers nach der angegebenen DLL durchsuchen. Wenn ein Angreifer eine schädliche Version einer DLL in das aktuelle Arbeitsverzeichnis kopiert hat, verweist der von SearchPath abgerufene Pfad auf die schädliche DLL, die LoadLibraryEx- dann lädt.
Machen Sie keine Annahmen über die Betriebssystemversion basierend auf einem LoadLibraryEx Aufruf, der nach einer DLL sucht. Wenn die Anwendung in einer Umgebung ausgeführt wird, in der die DLL legitim nicht vorhanden ist, aber eine schädliche Version der DLL sich im Suchpfad befindet, kann die schädliche Version der DLL geladen werden. Verwenden Sie stattdessen die empfohlenen Techniken, die unter Abrufen der Systemversionbeschrieben werden.
Eine allgemeine Erläuterung zu DLL-Sicherheitsproblemen finden Sie unter Dynamic-Link Bibliothekssicherheit.
Beispiele
Im folgenden Codebeispiel wird ein Aufruf von LoadLibraryExA-veranschaulicht.
//Load the FMAPI DLL
hLib = ::LoadLibraryEx(L"fmapi.dll", NULL, NULL);
if ( !hLib )
{
wprintf(L"Could not load fmapi.dll, Error #%d.\n", GetLastError());
return;
}
Ein weiteres Beispiel finden Sie unter Nachschlagen von Text für Fehlercodenummern.
Anmerkung
Der libloaderapi.h-Header definiert LoadLibraryEx als Alias, der automatisch die ANSI- oder Unicode-Version dieser Funktion basierend auf der Definition der UNICODE-Präprozessorkonstante auswählt. Das Mischen der Verwendung des codierungsneutralen Alias mit Code, der nicht codierungsneutral ist, kann zu Nichtübereinstimmungen führen, die zu Kompilierungs- oder Laufzeitfehlern führen. Weitere Informationen finden Sie unter Konventionen für Funktionsprototypen.
Anforderungen
| Anforderung | Wert |
|---|---|
| mindestens unterstützte Client- | Windows XP [nur Desktop-Apps] |
| mindestens unterstützte Server- | Windows Server 2003 [Nur Desktop-Apps] |
| Zielplattform- | Fenster |
| Header- | libloaderapi.h (include Windows.h) |
| Library | Kernel32.lib |
| DLL- | Kernel32.dll |
Siehe auch
Dynamic-Link Bibliotheksfunktionen
Dynamic-Link Bibliothekssuchreihenfolge
Dynamic-Link Bibliothekssicherheit
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter https://aka.ms/ContentUserFeedback.
Feedback senden und anzeigen für