LoadLibraryExA function (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 steht nicht im Zusammenhang mit dem Namen, der in einem Bibliotheksmodul selbst gespeichert ist, wie vom LIBRARY-Schlüsselwort (keyword) in der Moduldefinitionsdatei (.def) angegeben.
Das Modul kann ein Bibliotheksmodul (eine .dll-Datei) oder ein ausführbares Modul (eine .exe-Datei) sein. Wenn das angegebene Modul ein ausführbares Modul ist, werden statische Importe nicht geladen. stattdessen wird das Modul geladen, als ob DONT_RESOLVE_DLL_REFERENCES angegeben wäre. 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, umgekehrte Schrägstriche (\) und keine Schrägstriche (/) zu verwenden. Weitere Informationen zu Pfaden finden Sie unter Benennen von Dateien, Pfaden 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 angibt und ein Modul mit demselben Namen noch nicht geladen ist, 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, wenn das System andere zugeordnete Module lädt (wenn das Modul Abhängigkeiten aufweist). 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 Flags angegeben werden, ist das Verhalten dieser Funktion mit dem der LoadLibrary-Funktion identisch. Dieser Parameter kann einen der folgenden Werte annehmen.
| Wert | Bedeutung |
|---|---|
|
Wenn dieser Wert verwendet wird und das ausführbare Modul eine DLL ist, ruft das System DllMain nicht 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 mit der LoadLibrary-Funktion als DLL oder ausführbares Modul.
|
|
Wenn dieser Wert verwendet wird, überprüft das System keine AppLocker-Regeln und wendet keine Softwareeinschränkungsrichtlinien für die DLL an. Diese Aktion gilt nur für die geladene DLL und nicht für deren Abhängigkeiten. Dieser Wert wird zur 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 ist, 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 mit Windows 7 oder Windows Server 2008 R2 verwenden" in der Hilfe- und Support-Wissensdatenbank 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 unternommen, um die zugeordnete Datei auszuführen oder vorzubereiten. Daher können Sie mit dieser DLL keine Funktionen wie GetModuleFileName, GetModuleHandle oder GetProcAddress aufrufen. Die Verwendung dieses Werts bewirkt, dass Schreibvorgänge in den schreibgeschützten Arbeitsspeicher eine Zugriffsverletzung auslösen. 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_RESOURCE verwendet 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 aufrufenden Prozess geöffnet wird. Andere Prozesse können die DLL-Datei nicht für 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_RESOURCE verwendet 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 weder die statischen Importe noch führt er 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 davon abhängt, dass die Datei das Speicherlayout eines Bilds aufweist, sollte dieser Wert mit LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVE oder LOAD_LIBRARY_AS_DATAFILE verwendet werden. Weitere Informationen finden Sie im Abschnitt mit Hinweisen. 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 ihren Abhängigkeiten durchsucht. Verzeichnisse im Standardsuchpfad werden nicht durchsucht. Dieser Wert kann nicht mit LOAD_WITH_ALTERED_SEARCH_PATH kombiniert werden.
Windows 7, Windows Server 2008 R2, Windows Vista und Windows Server 2008: Für diesen Wert muss 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_SYSTEM32 und LOAD_LIBRARY_SEARCH_USER_DIRS. Verzeichnisse im Standardsuchpfad werden nicht durchsucht. Dieser Wert kann nicht mit LOAD_WITH_ALTERED_SEARCH_PATH kombiniert werden.
Dieser Wert stellt die empfohlene maximale Anzahl von Verzeichnissen dar, die eine Anwendung in den DLL-Suchpfad aufnehmen sollte. Windows 7, Windows Server 2008 R2, Windows Vista und Windows Server 2008: Für diesen Wert muss 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 Standardsuchpfad werden nicht durchsucht.
Der lpFileName-Parameter muss einen vollqualifizierten Pfad angeben. Dieser Wert kann nicht mit LOAD_WITH_ALTERED_SEARCH_PATH kombiniert werden. Wenn beispielsweise Lib2.dll eine Abhängigkeit von C:\Dir1\Lib1.dll ist, führt das Laden von Lib1.dll mit diesem Wert dazu, dass das System nur in C:\Dir1 nach Lib2.dll sucht. Um nach Lib2.dll in C:\Dir1 und allen Verzeichnissen im DLL-Suchpfad zu suchen, kombinieren Sie diesen Wert mit LOAD_LIBRARY_SEARCH_DEFAULT_DIRS. Windows 7, Windows Server 2008 R2, Windows Vista und Windows Server 2008: Für diesen Wert muss 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 ihren Abhängigkeiten gesucht.
Verzeichnisse im Standardsuchpfad werden nicht durchsucht. Dieser Wert kann nicht mit LOAD_WITH_ALTERED_SEARCH_PATH kombiniert werden.
Windows 7, Windows Server 2008 R2, Windows Vista und Windows Server 2008: Für diesen Wert muss KB2533623 installiert werden. Windows Server 2003 und Windows XP: Dieser Wert wird nicht unterstützt. |
|
Wenn dieser Wert verwendet wird, werden Verzeichnisse, die mit addDllDirectory oder der SetDllDirectory-Funktion hinzugefügt wurden, nach der DLL und ihren Abhängigkeiten gesucht. Wenn mehrere Verzeichnisse hinzugefügt wurden, ist die Reihenfolge, in der die Verzeichnisse durchsucht werden, nicht angegeben. Verzeichnisse im Standardsuchpfad werden nicht durchsucht. Dieser Wert kann nicht mit LOAD_WITH_ALTERED_SEARCH_PATH kombiniert werden.
Windows 7, Windows Server 2008 R2, Windows Vista und Windows Server 2008: Für diesen Wert muss 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 vom angegebenen Modul geladen werden. Wenn dieser Wert verwendet wird und lpFileName einen relativen Pfad angibt, ist das Verhalten nicht definiert.
Wenn dieser Wert nicht verwendet wird oder lpFileName keinen Pfad angibt, verwendet das System die im Abschnitt Hinweise erläuterte Standardsuchestrategie, um zugeordnete ausführbare Module zu finden, die vom angegebenen Modul geladen werden. Dieser Wert kann nicht mit einem LOAD_LIBRARY_SEARCH-Flag kombiniert werden. |
|
Gibt an, dass die digitale Signatur des Binärimages zur Ladezeit ü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 zur Ausführung aus dem aktuellen Verzeichnis nur zulässig, wenn sie sich unter einem Verzeichnis in der Liste Sichere Ladevorgänge befindet. |
Rückgabewert
Wenn die Funktion erfolgreich ist, ist der Rückgabewert ein Handle für das geladene Modul.
Wenn bei der Funktion ein Fehler auftritt, ist der Rückgabewert NULL. Um erweiterte Fehlerinformationen zu erhalten, rufen Sie GetLastError auf.
Hinweise
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, in dem das Modul nie ausgeführt wird, und lädt das Modul so, als wäre es eine Datendatei.
- LoadLibraryEx kann Module und die zugehörigen Module mithilfe einer von zwei Suchstrategien suchen oder einen prozessspezifischen Satz von Verzeichnissen durchsuchen.
Der aufrufende Prozess kann das von LoadLibraryEx zurückgegebene Handle verwenden, um das Modul in Aufrufen der Funktionen GetProcAddress, FindResource und LoadResource zu identifizieren.
Verwenden Sie die SetErrorMode-Funktion , um Fehlermeldungen zu aktivieren oder zu deaktivieren, die vom Ladeprogramm während des DLL-Ladevorgangs angezeigt werden.
Es ist nicht sicher, LoadLibraryEx über DllMain aufzurufen. Weitere Informationen finden Sie im Abschnitt Hinweise in DllMain.
Visual C++: Der Visual C++-Compiler unterstützt eine Syntax, mit der Sie lokale Threadvariablen deklarieren können: _declspec(thread). Wenn Sie diese Syntax in einer DLL verwenden, können Sie die DLL nicht explizit mit LoadLibraryEx auf Windows-Versionen vor Windows Vista laden. Wenn Ihre DLL explizit geladen wird, müssen Sie die lokalen Speicherfunktionen des Threads anstelle von _declspec(thread) verwenden. Ein Beispiel finden Sie unter Verwenden des lokalen Threadspeichers in einer Dynamic Link-Bibliothek.
Laden einer DLL als Datendatei oder Bildressource
Die werte LOAD_LIBRARY_AS_DATAFILE, LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVE und LOAD_LIBRARY_AS_IMAGE_RESOURCE wirken sich auf die Anzahl der Referenzdaten pro Prozess und das Laden des angegebenen Moduls aus. Wenn einer 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. In diesem Fall bedeutet dies, dass das Modul bereits dem virtuellen Adressraum des aufrufenden Prozesses zugeordnet ist. In diesem Fall gibt LoadLibraryEx ein Handle für die DLL zurück und erhöht die DLL-Referenzanzahl. Wenn das DLL-Modul nicht bereits als DLL geladen wurde, ordnet das System das Modul als Daten- oder Imagedatei und nicht als ausführbare DLL zu. In diesem Fall gibt LoadLibraryEx ein Handle für die geladene Daten- oder Imagedatei zurück, erhöht jedoch nicht die Verweisanzahl für das Modul und macht das Modul nicht für Funktionen wie CreateToolhelp32Snapshot oder EnumProcessModules sichtbar.Wenn LoadLibraryEx zweimal für dieselbe Datei mit LOAD_LIBRARY_AS_DATAFILE, LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVE oder LOAD_LIBRARY_AS_IMAGE_RESOURCE aufgerufen 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 geladen, indem die Pe-Abschnittsausrichtungserweiterung (Portable Executable) verwendet wird. Relative virtuelle Adressen (RVA) müssen nicht Datenträgeradressen zugeordnet werden, sodass Ressourcen schneller aus dem Modul abgerufen werden können. Die Angabe LOAD_LIBRARY_AS_IMAGE_RESOURCE verhindert, dass andere Prozesse das Modul ändern, während es geladen wird.
Sofern eine Anwendung nicht von bestimmten Bildzuordnungseigenschaften abhängig ist, sollte der LOAD_LIBRARY_AS_IMAGE_RESOURCE Wert entweder mit LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVE oder LOAD_LIBRARY_AS_DATAFILE verwendet werden. Dadurch kann der Ladevorgang auswählen, ob das Modul als Bildressource oder als Datendatei geladen werden soll. Wählen Sie die option aus, die es dem System ermöglicht, Seiten effektiver freizugeben. Ressourcenfunktionen wie FindResource können beide Zuordnungen verwenden.
Um zu bestimmen, wie ein Modul geladen wurde, verwenden Sie eines der folgenden Makros, um das von LoadLibraryEx zurü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 (LOAD_LIBRARY_AS_DATAFILE oder LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVE) geladen. |
| LDR_IS_IMAGEMAPPING(handle) | Wenn dieses Makro TRUE zurü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 Imagedatei geladen. |
Verwenden Sie die FreeLibrary-Funktion , um ein geladenes Modul frei zu geben, unabhängig davon, ob das Laden des Moduls dazu führte, dass die Verweisanzahl erhöht wurde. Wenn das Modul als Daten- oder Imagedatei geladen wurde, wird die Zuordnung zerstört, aber die Verweisanzahl wird nicht verringert. Andernfalls wird die DLL-Verweisanzahl verringert. Daher ist es sicher, FreeLibrary mit jedem von LoadLibraryEx zurückgegebenen Handle aufzurufen.
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 Standardsuchpfads oder eines geänderten Suchpfads nach einer DLL suchen oder einen prozessspezifischen Suchpfad verwenden, der mit den Funktionen SetDefaultDllDirectories und AddDllDirectory eingerichtet wurde. Eine Liste der Verzeichnisse und die Reihenfolge, in der sie durchsucht werden, finden Sie unter Dynamic-Link Library Search Order.Die LoadLibraryEx-Funktion verwendet in den folgenden Fällen den Standardsuchpfad:
- 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 wird verwendet.
- Es wird ein Pfad angegeben, aber LOAD_WITH_ALTERED_SEARCH_PATH nicht verwendet.
- Die Anwendung hat keinen standardmäßigen DLL-Suchpfad für den Prozess mit SetDefaultDllDirectories angegeben.
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 rufen Sie LoadLibraryEx mit dem nichtrelativen Pfad auf. 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_PATH festgelegt ist, verwendet LoadLibraryEx den geänderten Suchpfad. Das Verhalten ist nicht definiert, wenn LOAD_WITH_ALTERED_SEARCH_PATH Flag festgelegt ist und lpFileName einen relativen Pfad angibt.
Die SetDllDirectory-Funktion kann verwendet werden, um den Suchpfad zu ändern. Diese Lösung ist besser, als SetCurrentDirectory zu verwenden oder den vollständigen Pfad zur DLL hart zu codieren. 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 Prozesssuchpfad zu ändern. Weitere Informationen finden Sie unter Dynamic-Link Library Search Order.
Eine Anwendung kann die Verzeichnisse angeben, die nach einem einzelnen LoadLibraryEx-Aufruf suchen sollen, indem sie die LOAD_LIBRARY_SEARCH_* -Flags verwendet. Wenn mehr als ein LOAD_LIBRARY_SEARCH Flag angegeben ist, 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 dem Anwendungssuchpfad explizit mit der Funktion AddDllDirectory (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 zu ermitteln, ob die Flags verfügbar sind, verwenden Sie GetProcAddress , um die Adresse der Funktion AddDllDirectory, RemoveDllDirectory oder SetDefaultDllDirectories 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 Standardsuchpfads.
Wenn ein Pfad angegeben ist und der Anwendung eine Umleitungsdatei zugeordnet ist, sucht die LoadLibraryEx-Funktion im Anwendungsverzeichnis nach dem Modul. Wenn das Modul im Anwendungsverzeichnis vorhanden ist, ignoriert LoadLibraryEx die Pfadspezifikation und lädt das Modul aus dem Anwendungsverzeichnis. 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.For more information, see Dynamic Link Library Redirection.
Wenn Sie LoadLibraryEx mit dem Namen einer Assembly ohne Pfadangabe aufrufen und die Assembly im systemkompatiblen Manifest aufgeführt ist, wird der Aufruf automatisch an die parallele Assembly umgeleitet.
Sicherheitsbemerkungen
LOAD_LIBRARY_AS_DATAFILE verhindert nicht, dass andere Prozesse das Modul während des Ladens ändern. Da dies ihre Anwendung weniger sicher machen kann, sollten Sie beim Laden eines Moduls als Datendatei LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVE anstelle von LOAD_LIBRARY_AS_DATAFILE verwenden, es sei denn, Sie müssen ausdrücklich LOAD_LIBRARY_AS_DATAFILE verwenden. Die Angabe LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVE verhindert, dass andere Prozesse das Modul während des Ladens ändern. Geben Sie nicht LOAD_LIBRARY_AS_DATAFILE und LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVE im gleichen Aufruf 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 nicht den Suchmodus für sichere Prozesse, es sei denn, dies wird explizit durch Aufrufen von SetSearchPathMode mit BASE_SEARCH_PATH_ENABLE_SAFE_SEARCHMODE aktiviert. Daher durchsucht SearchPath wahrscheinlich zuerst das aktuelle Arbeitsverzeichnis des Benutzers nach der angegebenen DLL. Wenn ein Angreifer eine böswillige Version einer DLL in das aktuelle Arbeitsverzeichnis kopiert hat, verweist der von SearchPath abgerufene Pfad auf die schädliche DLL, die dann von LoadLibraryEx geladen wird.
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, sich aber eine böswillige Version der DLL im Suchpfad befindet, kann die schädliche Version der DLL geladen werden. Verwenden Sie stattdessen die empfohlenen Techniken, die unter Abrufen der Systemversion beschrieben werden.
Eine allgemeine Erläuterung der DLL-Sicherheitsprobleme finden Sie unter Dynamic-Link Library Security.
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 Suchen nach Text für Fehlercodenummern.
Hinweis
Der libloaderapi.h-Header definiert LoadLibraryEx als Alias, der die ANSI- oder Unicode-Version dieser Funktion basierend auf der Definition der UNICODE-Präprozessorkonstante automatisch 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 |
|---|---|
| Unterstützte Mindestversion (Client) | Windows XP [nur Desktop-Apps] |
| Unterstützte Mindestversion (Server) | Windows Server 2003 [nur Desktop-Apps] |
| Zielplattform | Windows |
| Kopfzeile | libloaderapi.h (Einschließen von Windows.h) |
| Bibliothek | Kernel32.lib |
| DLL | Kernel32.dll |
Siehe auch
Dynamic-Link-Bibliotheksfunktionen
Dynamic Link Library-Suchreihenfolge
Sicherheit der Dynamic Link-Bibliothek
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