Partager via


LoadLibraryExW, fonction (libloaderapi.h)

Charge le module spécifié dans l’espace d’adressage du processus appelant. Le module spécifié peut entraîner le chargement d’autres modules.

Syntaxe

HMODULE LoadLibraryExW(
  [in] LPCWSTR lpLibFileName,
       HANDLE  hFile,
  [in] DWORD   dwFlags
);

Paramètres

[in] lpLibFileName

Chaîne qui spécifie le nom de fichier du module à charger. Ce nom n’est pas lié au nom stocké dans un module de bibliothèque lui-même, tel que spécifié par le mot clé LIBRARY dans le fichier de définition de module (.def).

Le module peut être un module de bibliothèque (un fichier .dll) ou un module exécutable (un fichier .exe). Si le module spécifié est un module exécutable, les importations statiques ne sont pas chargées ; au lieu de cela, le module est chargé comme si DONT_RESOLVE_DLL_REFERENCES était spécifié. Pour plus d’informations, consultez le paramètre dwFlags .

Si la chaîne spécifie un nom de module sans chemin d’accès et que l’extension de nom de fichier est omise et que le nom du module ne contient aucun caractère de point (.), la fonction ajoute l’extension de bibliothèque par défaut « .DLL » au nom du module. Pour empêcher la fonction d’ajouter « .DLL » au nom du module, incluez un caractère de point de fin (.) dans la chaîne de nom du module.

Si la chaîne spécifie un chemin d’accès complet, la fonction recherche uniquement ce chemin d’accès pour le module. Lorsque vous spécifiez un chemin d’accès, veillez à utiliser des barres obliques inverses (\), et non des barres obliques (/). Pour plus d’informations sur les chemins d’accès, consultez Naming Files, Paths, and Namespaces.

Si la chaîne spécifie un nom de module sans chemin d’accès et que plusieurs modules chargés ont le même nom de base et la même extension, la fonction retourne un handle au module qui a été chargé en premier.

Si la chaîne spécifie un nom de module sans chemin d’accès et qu’un module du même nom n’est pas déjà chargé, ou si la chaîne spécifie un nom de module avec un chemin relatif, la fonction recherche le module spécifié. La fonction recherche également des modules si le chargement du module spécifié entraîne le chargement par le système d’autres modules associés (autrement dit, si le module a des dépendances). Les répertoires recherchés et l’ordre dans lequel ils sont recherchés dépendent du chemin d’accès spécifié et du paramètre dwFlags . Pour plus d'informations, consultez la section Notes.

Si la fonction ne trouve pas le module ou l’une de ses dépendances, la fonction échoue.

hFile

Ce paramètre est réservé à un usage futur. Elle doit être NULL.

[in] dwFlags

Action à effectuer lors du chargement du module. Si aucun indicateur n’est spécifié, le comportement de cette fonction est identique à celui de la fonction LoadLibrary . Ce paramètre peut prendre les valeurs suivantes.

Valeur Signification
DONT_RESOLVE_DLL_REFERENCES
0x00000001
Si cette valeur est utilisée et que le module exécutable est une DLL, le système n’appelle pas DllMain pour l’initialisation et l’arrêt du processus et du thread. En outre, le système ne charge pas de modules exécutables supplémentaires référencés par le module spécifié.
Note N’utilisez pas cette valeur ; il est fourni uniquement à des fins de compatibilité descendante. Si vous envisagez d’accéder uniquement aux données ou aux ressources de la DLL, utilisez LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVE ou LOAD_LIBRARY_AS_IMAGE_RESOURCE ou les deux. Sinon, chargez la bibliothèque en tant que module DLL ou exécutable à l’aide de la fonction LoadLibrary .
 
LOAD_IGNORE_CODE_AUTHZ_LEVEL
0x00000010
Si cette valeur est utilisée, le système ne case activée pas les règles AppLocker ou n’applique pas de stratégies de restriction logicielle pour la DLL. Cette action s’applique uniquement à la DLL en cours de chargement et non à ses dépendances. Cette valeur est recommandée pour une utilisation dans les programmes d’installation qui doivent exécuter des DLL extraites pendant l’installation.

Windows Server 2008 R2 et Windows 7 : Sur les systèmes sur utilisant KB2532445 installés, l’appelant doit s’exécuter en tant que « LocalSystem » ou « TrustedInstaller » ; sinon, le système ignore cet indicateur. Pour plus d’informations, consultez « Vous pouvez contourner les règles AppLocker à l’aide d’une macro Office sur un ordinateur exécutant Windows 7 ou Windows Server 2008 R2 » dans la Base de connaissances d’aide et de support à l’adresse https://support.microsoft.com/kb/2532445.

Windows Server 2008, Windows Vista, Windows Server 2003 et Windows XP : AppLocker a été introduit dans Windows 7 et Windows Server 2008 R2.

LOAD_LIBRARY_AS_DATAFILE
0x00000002
Si cette valeur est utilisée, le système mappe le fichier dans l’espace d’adressage virtuel du processus appelant comme s’il s’agissait d’un fichier de données. Rien n’est fait pour exécuter ou préparer l’exécution du fichier mappé. Par conséquent, vous ne pouvez pas appeler des fonctions telles que GetModuleFileName, GetModuleHandle ou GetProcAddress avec cette DLL. Si vous utilisez cette valeur, les écritures en mémoire en lecture seule déclenchent une violation d’accès. Utilisez cet indicateur lorsque vous souhaitez charger une DLL uniquement pour en extraire des messages ou des ressources.

Cette valeur peut être utilisée avec LOAD_LIBRARY_AS_IMAGE_RESOURCE. Pour plus d'informations, consultez la section Notes.

LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVE
0x00000040
Semblable à LOAD_LIBRARY_AS_DATAFILE, sauf que le fichier DLL est ouvert avec un accès en écriture exclusif pour le processus appelant. D’autres processus ne peuvent pas ouvrir le fichier DLL pour un accès en écriture pendant son utilisation. Toutefois, la DLL peut toujours être ouverte par d’autres processus.

Cette valeur peut être utilisée avec LOAD_LIBRARY_AS_IMAGE_RESOURCE. Pour plus d'informations, consultez la section Notes.

Windows Server 2003 et Windows XP : Cette valeur n’est pas prise en charge tant que Windows Vista n’est pas pris en charge.

LOAD_LIBRARY_AS_IMAGE_RESOURCE
0x00000020
Si cette valeur est utilisée, le système mappe le fichier dans l’espace d’adressage virtuel du processus en tant que fichier image. Toutefois, le chargeur ne charge pas les importations statiques ni n’effectue les autres étapes d’initialisation habituelles. Utilisez cet indicateur lorsque vous souhaitez charger une DLL uniquement pour en extraire des messages ou des ressources.

Sauf si l’application dépend du fichier ayant la disposition en mémoire d’une image, cette valeur doit être utilisée avec LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVE ou LOAD_LIBRARY_AS_DATAFILE. Pour plus d'informations, consultez la section Notes.

Windows Server 2003 et Windows XP : Cette valeur n’est pas prise en charge tant que Windows Vista n’est pas pris en charge.

LOAD_LIBRARY_SEARCH_APPLICATION_DIR
0x00000200
Si cette valeur est utilisée, le répertoire d’installation de l’application est recherché pour la DLL et ses dépendances. Les répertoires du chemin de recherche standard ne font pas l’objet d’une recherche. Cette valeur ne peut pas être combinée avec LOAD_WITH_ALTERED_SEARCH_PATH.

Windows 7, Windows Server 2008 R2, Windows Vista et Windows Server 2008 : Cette valeur nécessite l’installation de KB2533623 .

Windows Server 2003 et Windows XP : Cette valeur n’est pas prise en charge.

LOAD_LIBRARY_SEARCH_DEFAULT_DIRS
0x00001000
Cette valeur est une combinaison de LOAD_LIBRARY_SEARCH_APPLICATION_DIR, de LOAD_LIBRARY_SEARCH_SYSTEM32 et de LOAD_LIBRARY_SEARCH_USER_DIRS. Les répertoires du chemin de recherche standard ne font pas l’objet d’une recherche. Cette valeur ne peut pas être combinée avec LOAD_WITH_ALTERED_SEARCH_PATH.

Cette valeur représente le nombre maximal recommandé de répertoires qu’une application doit inclure dans son chemin de recherche dll.

Windows 7, Windows Server 2008 R2, Windows Vista et Windows Server 2008 : Cette valeur nécessite l’installation de KB2533623 .

Windows Server 2003 et Windows XP : Cette valeur n’est pas prise en charge.

LOAD_LIBRARY_SEARCH_DLL_LOAD_DIR
0x00000100
Si cette valeur est utilisée, le répertoire qui contient la DLL est temporairement ajouté au début de la liste des répertoires recherchés pour les dépendances de la DLL. Les répertoires du chemin de recherche standard ne font pas l’objet d’une recherche.

Le paramètre lpFileName doit spécifier un chemin d’accès complet. Cette valeur ne peut pas être combinée avec LOAD_WITH_ALTERED_SEARCH_PATH.

Par exemple, si Lib2.dll est une dépendance de C:\Dir1\Lib1.dll, le chargement de Lib1.dll avec cette valeur entraîne la recherche de Lib2.dll uniquement dans C:\Dir1. Pour rechercher Lib2.dll dans C:\Dir1 et tous les répertoires dans le chemin de recherche dll, combinez cette valeur avec LOAD_LIBRARY_DEFAULT_DIRS.

Windows 7, Windows Server 2008 R2, Windows Vista et Windows Server 2008 : Cette valeur nécessite l’installation de KB2533623 .

Windows Server 2003 et Windows XP : Cette valeur n’est pas prise en charge.

LOAD_LIBRARY_SEARCH_SYSTEM32
0x00000800
Si cette valeur est utilisée, %windows%\system32 est recherché pour la DLL et ses dépendances. Les répertoires du chemin de recherche standard ne font pas l’objet d’une recherche. Cette valeur ne peut pas être combinée avec LOAD_WITH_ALTERED_SEARCH_PATH.

Windows 7, Windows Server 2008 R2, Windows Vista et Windows Server 2008 : Cette valeur nécessite l’installation de KB2533623 .

Windows Server 2003 et Windows XP : Cette valeur n’est pas prise en charge.

LOAD_LIBRARY_SEARCH_USER_DIRS
0x00000400
Si cette valeur est utilisée, les répertoires ajoutés à l’aide de la fonction AddDllDirectory ou SetDllDirectory sont recherchés pour la DLL et ses dépendances. Si plusieurs répertoires ont été ajoutés, l’ordre dans lequel les répertoires sont recherchés n’est pas spécifié. Les répertoires du chemin de recherche standard ne font pas l’objet d’une recherche. Cette valeur ne peut pas être combinée avec LOAD_WITH_ALTERED_SEARCH_PATH.

Windows 7, Windows Server 2008 R2, Windows Vista et Windows Server 2008 : Cette valeur nécessite l’installation de KB2533623 .

Windows Server 2003 et Windows XP : Cette valeur n’est pas prise en charge.

LOAD_WITH_ALTERED_SEARCH_PATH
0x00000008
Si cette valeur est utilisée et que lpFileName spécifie un chemin absolu, le système utilise la stratégie de recherche de fichiers alternative décrite dans la section Notes pour rechercher les modules exécutables associés que le module spécifié fait charger. Si cette valeur est utilisée et que lpFileName spécifie un chemin relatif, le comportement n’est pas défini.

Si cette valeur n’est pas utilisée ou si lpFileName ne spécifie pas de chemin d’accès, le système utilise la stratégie de recherche standard décrite dans la section Remarques pour rechercher les modules exécutables associés que le module spécifié fait charger.

Cette valeur ne peut pas être combinée avec un indicateur de LOAD_LIBRARY_SEARCH .

LOAD_LIBRARY_REQUIRE_SIGNED_TARGET
0x00000080
Spécifie que la signature numérique de l’image binaire doit être vérifiée au moment du chargement.

Cette valeur nécessite Windows 8.1, Windows 10 ou version ultérieure.

LOAD_LIBRARY_SAFE_CURRENT_DIRS
0x00002000
Si cette valeur est utilisée, le chargement d’une DLL pour exécution à partir du répertoire actif n’est autorisé que s’il se trouve sous un répertoire dans la liste Chargement sécurisé.

Valeur retournée

Si la fonction réussit, la valeur de retour est un handle pour le module chargé.

Si la fonction échoue, la valeur de retour est NULL. Pour obtenir des informations détaillées sur l’erreur, appelez GetLastError.

Notes

La fonction LoadLibraryEx est très similaire à la fonction LoadLibrary . Les différences se composent d’un ensemble de comportements facultatifs que LoadLibraryEx fournit :

  • LoadLibraryEx peut charger un module DLL sans appeler la fonction DllMain de la DLL.
  • LoadLibraryEx peut charger un module d’une manière optimisée pour le cas où le module ne sera jamais exécuté, en chargeant le module comme s’il s’agissait d’un fichier de données.
  • LoadLibraryEx peut rechercher des modules et leurs modules associés à l’aide de l’une des deux stratégies de recherche ou rechercher un ensemble de répertoires spécifiques au processus.
Vous sélectionnez ces comportements facultatifs en définissant le paramètre dwFlags ; si dwFlags est égal à zéro, LoadLibraryEx se comporte de manière identique à LoadLibrary.

Le processus appelant peut utiliser le handle retourné par LoadLibraryEx pour identifier le module dans les appels aux fonctions GetProcAddress, FindResource et LoadResource .

Pour activer ou désactiver les messages d’erreur affichés par le chargeur pendant les chargements de DLL, utilisez la fonction SetErrorMode .

Il n’est pas sûr d’appeler LoadLibraryEx à partir de DllMain. Pour plus d’informations, consultez la section Notes dans DllMain.

Visual C++ : Le compilateur Visual C++ prend en charge une syntaxe qui vous permet de déclarer des variables locales de thread : _declspec(thread). Si vous utilisez cette syntaxe dans une DLL, vous ne pourrez pas charger la DLL explicitement à l’aide de LoadLibraryEx sur les versions de Windows antérieures à Windows Vista. Si votre DLL est chargée explicitement, vous devez utiliser les fonctions de stockage local de thread au lieu de _declspec(thread). Pour obtenir un exemple, consultez Utilisation du stockage local de threads dans une bibliothèque de liens dynamiques.

Chargement d’une DLL en tant que ressource de fichier de données ou d’image

Les valeurs LOAD_LIBRARY_AS_DATAFILE, LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVE et LOAD_LIBRARY_AS_IMAGE_RESOURCE affectent le nombre de références par processus et le chargement du module spécifié. Si l’une de ces valeurs est spécifiée pour le paramètre dwFlags , le chargeur vérifie si le module a déjà été chargé par le processus en tant que DLL exécutable. Si tel est le cas, cela signifie que le module est déjà mappé à l’espace d’adressage virtuel du processus appelant. Dans ce cas, LoadLibraryEx retourne un handle à la DLL et incrémente le nombre de références dll. Si le module DLL n’a pas déjà été chargé en tant que DLL, le système mappe le module en tant que fichier de données ou d’image et non en tant que DLL exécutable. Dans ce cas, LoadLibraryEx renvoie un handle au fichier de données ou image chargé, mais n’incrémente pas le nombre de références pour le module et ne rend pas le module visible pour des fonctions telles que CreateToolhelp32Snapshot ou EnumProcessModules.

Si LoadLibraryEx est appelé deux fois pour le même fichier avec LOAD_LIBRARY_AS_DATAFILE, LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVE ou LOAD_LIBRARY_AS_IMAGE_RESOURCE, deux mappages distincts sont créés pour le fichier.

Lorsque la valeur LOAD_LIBRARY_AS_IMAGE_RESOURCE est utilisée, le module est chargé en tant qu’image à l’aide de l’extension d’alignement de section exécutable portable (PE). Les adresses virtuelles relatives (RVA) n’ont pas besoin d’être mappées aux adresses de disque, de sorte que les ressources peuvent être récupérées plus rapidement à partir du module. La spécification de LOAD_LIBRARY_AS_IMAGE_RESOURCE empêche d’autres processus de modifier le module pendant son chargement.

Sauf si une application dépend de caractéristiques de mappage d’images spécifiques, la valeur LOAD_LIBRARY_AS_IMAGE_RESOURCE doit être utilisée avec LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVE ou LOAD_LIBRARY_AS_DATAFILE. Cela permet au chargeur de choisir s’il faut charger le module en tant que ressource d’image ou fichier de données, en sélectionnant l’option qui permet au système de partager des pages plus efficacement. Les fonctions de ressource telles que FindResource peuvent utiliser l’un ou l’autre mappage.

Pour déterminer comment un module a été chargé, utilisez l’une des macros suivantes pour tester le handle retourné par LoadLibraryEx.

#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))

Le tableau suivant décrit ces macros.

Macro Description
LDR_IS_DATAFILE(handle) Si cette macro retourne TRUE, le module a été chargé en tant que fichier de données (LOAD_LIBRARY_AS_DATAFILE ou LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVE).
LDR_IS_IMAGEMAPPING(handle) Si cette macro retourne TRUE, le module a été chargé en tant que fichier image (LOAD_LIBRARY_AS_IMAGE_RESOURCE).
LDR_IS_RESOURCE(handle) Si cette macro retourne TRUE, le module a été chargé en tant que fichier de données ou fichier image.
 

Utilisez la fonction FreeLibrary pour libérer un module chargé, que le chargement du module ait ou non provoqué l’incrémentation de son nombre de références. Si le module a été chargé en tant que fichier de données ou d’image, le mappage est détruit, mais le nombre de références n’est pas décrémenté. Sinon, le nombre de références DLL est décrémenté. Par conséquent, il est sûr d’appeler FreeLibrary avec n’importe quel handle retourné par LoadLibraryEx.

Recherche de DLL et de dépendances

Le chemin de recherche est l’ensemble des répertoires recherchés pour une DLL. La fonction LoadLibraryEx peut rechercher une DLL à l’aide d’un chemin de recherche standard ou d’un chemin de recherche modifié, ou elle peut utiliser un chemin de recherche spécifique au processus établi avec les fonctions SetDefaultDllDirectories et AddDllDirectory . Pour obtenir la liste des répertoires et l’ordre dans lequel ils sont recherchés, consultez Ordre de recherche de bibliothèque de liens dynamiques.

La fonction LoadLibraryEx utilise le chemin de recherche standard dans les cas suivants :

  • Le nom de fichier est spécifié sans chemin d’accès et le nom de fichier de base ne correspond pas au nom de fichier de base d’un module chargé, et aucun des indicateurs de LOAD_LIBRARY_SEARCH n’est utilisé.
  • Un chemin d’accès est spécifié, mais LOAD_WITH_ALTERED_SEARCH_PATH n’est pas utilisé.
  • L’application n’a pas spécifié de chemin de recherche DLL par défaut pour le processus à l’aide de SetDefaultDllDirectories.

Si lpFileName spécifie un chemin relatif, le chemin d’accès relatif entier est ajouté à chaque jeton dans le chemin de recherche de DLL. Pour charger un module à partir d’un chemin relatif sans rechercher d’autre chemin, utilisez GetFullPathName pour obtenir un chemin d’accès non relationnel et appelez LoadLibraryEx avec le chemin d’accès non relationnel. Si le module est chargé en tant que fichier de données et que le chemin d’accès relatif commence par « » ou « . », le chemin relatif est traité comme un chemin absolu.

Si lpFileName spécifie un chemin absolu et que dwFlags est défini sur LOAD_WITH_ALTERED_SEARCH_PATH, LoadLibraryEx utilise le chemin de recherche modifié. Le comportement n’est pas défini lorsque LOAD_WITH_ALTERED_SEARCH_PATH indicateur est défini et que lpFileName spécifie un chemin relatif.

La fonction SetDllDirectory peut être utilisée pour modifier le chemin de recherche. Cette solution est préférable à l’utilisation de SetCurrentDirectory ou au codage en dur du chemin d’accès complet à la DLL. Toutefois, n’oubliez pas que l’utilisation de SetDllDirectory désactive efficacement le mode de recherche de DLL sécurisé lorsque le répertoire spécifié se trouve dans le chemin de recherche et qu’il n’est pas thread-safe. Si possible, il est préférable d’utiliser AddDllDirectory pour modifier un chemin de recherche de processus par défaut. Pour plus d’informations, consultez Ordre de recherche de bibliothèque de liens dynamiques.

Une application peut spécifier les répertoires à rechercher pour un seul appel LoadLibraryEx à l’aide des indicateurs LOAD_LIBRARY_SEARCH_* . Si plusieurs indicateurs LOAD_LIBRARY_SEARCH sont spécifiés, les répertoires sont recherchés dans l’ordre suivant :

  • Répertoire qui contient la DLL (LOAD_LIBRARY_SEARCH_DLL_LOAD_DIR). Ce répertoire est recherché uniquement pour les dépendances de la DLL à charger.
  • Répertoire de l’application (LOAD_LIBRARY_SEARCH_APPLICATION_DIR).
  • Chemins d’accès explicitement ajoutés au chemin de recherche d’application avec la fonction AddDllDirectory (LOAD_LIBRARY_SEARCH_USER_DIRS) ou la fonction SetDllDirectory . Si plusieurs chemins ont été ajoutés, l’ordre dans lequel les chemins sont recherchés n’est pas spécifié.
  • Répertoire System32 (LOAD_LIBRARY_SEARCH_SYSTEM32).

Windows 7, Windows Server 2008 R2, Windows Vista et Windows Server 2008 : Les indicateurs de LOAD_LIBRARY_SEARCH_ sont disponibles sur les systèmes qui ont KB2533623 installés. Pour déterminer si les indicateurs sont disponibles, utilisez GetProcAddress pour obtenir l’adresse de la fonction AddDllDirectory, RemoveDllDirectory ou SetDefaultDllDirectories . Si GetProcAddress réussit, les indicateurs LOAD_LIBRARY_SEARCH_ peuvent être utilisés avec LoadLibraryEx.

Si l’application a utilisé la fonction SetDefaultDllDirectories pour établir un chemin de recherche DLL pour le processus et qu’aucun indicateur LOAD_LIBRARY_SEARCH_* n’est utilisé, la fonction LoadLibraryEx utilise le chemin de recherche de la DLL de processus au lieu du chemin de recherche standard.

Si un chemin d’accès est spécifié et qu’un fichier de redirection est associé à l’application, la fonction LoadLibraryEx recherche le module dans le répertoire de l’application. Si le module existe dans le répertoire de l’application, LoadLibraryEx ignore la spécification du chemin d’accès et charge le module à partir du répertoire de l’application. Si le module n’existe pas dans le répertoire de l’application, la fonction charge le module à partir du répertoire spécifié. Pour plus d’informations, consultez Redirection de bibliothèque de liens dynamiques.

Si vous appelez LoadLibraryEx avec le nom d’un assembly sans spécification de chemin et que l’assembly est répertorié dans le manifeste compatible système, l’appel est automatiquement redirigé vers l’assembly côte à côte.

Remarques sur la sécurité

LOAD_LIBRARY_AS_DATAFILE n’empêche pas d’autres processus de modifier le module pendant son chargement. Étant donné que cela peut rendre votre application moins sécurisée, vous devez utiliser LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVE au lieu de LOAD_LIBRARY_AS_DATAFILE lors du chargement d’un module en tant que fichier de données, sauf si vous avez spécifiquement besoin d’utiliser LOAD_LIBRARY_AS_DATAFILE. La spécification de LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVE empêche d’autres processus de modifier le module pendant son chargement. Ne spécifiez pas LOAD_LIBRARY_AS_DATAFILE et LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVE dans le même appel.

N’utilisez pas la fonction SearchPath pour récupérer un chemin d’accès à une DLL pour un appel LoadLibraryEx suivant. La fonction SearchPath utilise un ordre de recherche différent de celui de LoadLibraryEx et n’utilise pas le mode de recherche de processus sécurisé, sauf si cela est explicitement activé en appelant SetSearchPathMode avec BASE_SEARCH_PATH_ENABLE_SAFE_SEARCHMODE. Par conséquent, SearchPath est susceptible de rechercher d’abord la DLL spécifiée dans le répertoire de travail actuel de l’utilisateur. Si un attaquant a copié une version malveillante d’une DLL dans le répertoire de travail actuel, le chemin récupéré par SearchPath pointe vers la DLL malveillante, que LoadLibraryEx chargera ensuite.

N’effectuez pas d’hypothèses sur la version du système d’exploitation basée sur un appel LoadLibraryEx qui recherche une DLL. Si l’application s’exécute dans un environnement où la DLL n’est légitimement pas présente, mais qu’une version malveillante de la DLL se trouve dans le chemin de recherche, la version malveillante de la DLL peut être chargée. Utilisez plutôt les techniques recommandées décrites dans Obtention de la version du système.

Pour une présentation générale des problèmes de sécurité des DLL, consultez Sécurité de la bibliothèque Dynamic-Link.

Exemples

Pour obtenir un exemple, consultez Recherche de texte pour les numéros de code d’erreur.

Notes

L’en-tête libloaderapi.h définit LoadLibraryEx comme alias qui sélectionne automatiquement la version ANSI ou Unicode de cette fonction en fonction de la définition de la constante de préprocesseur UNICODE. La combinaison de l’utilisation de l’alias neutre en encodage avec du code qui n’est pas neutre en encodage peut entraîner des incompatibilités qui entraînent des erreurs de compilation ou d’exécution. Pour plus d’informations, consultez Conventions pour les prototypes de fonction.

Spécifications

   
Client minimal pris en charge Windows XP [applications de bureau uniquement]
Serveur minimal pris en charge Windows Server 2003 [applications de bureau uniquement]
Plateforme cible Windows
En-tête libloaderapi.h (inclure Windows.h)
Bibliothèque Kernel32.lib
DLL Kernel32.dll

Voir aussi

DllMain

Fonctions de bibliothèque de liens dynamiques

Ordre de recherche de bibliothèque de liens dynamiques

Sécurité de la bibliothèque de liens dynamiques

FindResource

FreeLibrary

GetProcAddress

GetSystemDirectory

GetWindowsDirectory

LoadLibrary

LoadResource

OpenFile

Liaison dynamique au moment de l’exécution

SearchPath

SetDllDirectory

SetErrorMode