LoadLibraryExA, fonction (libloaderapi.h)

Article
03/11/2023

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 LoadLibraryExA(
  [in] LPCSTR 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, comme 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, 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 du nom du module.

Si la chaîne spécifie un chemin 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 Nommer des fichiers, des chemins et des espaces de noms.

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 l’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 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 pour la 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 DLL ou module 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 aide et 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. L’utilisation de cette valeur entraîne les écritures dans la mémoire en lecture seule pour déclencher 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 d’appel. D’autres processus ne peuvent pas ouvrir le fichier DLL pour l’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 prise en charge que sous Windows Vista.
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 prise en charge que sous Windows Vista.
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, LOAD_LIBRARY_SEARCH_SYSTEM32 et 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 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 du chemin de recherche dll, combinez cette valeur avec LOAD_LIBRARY_SEARCH_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 d’accès absolu, le système utilise la stratégie de recherche de fichiers alternative décrite dans la section Remarques 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 l’exécution à partir du répertoire actif n’est autorisé que s’il se trouve dans 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.

Remarques

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 d’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 Remarques 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 des 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 c’est le cas, cela signifie que le module est déjà mappé dans 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 encore é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 retourne un handle au fichier de données ou d’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.

À moins qu’une application ne 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 ressources 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é sous la forme d’un fichier de données ou d’un fichier image.

Utilisez la fonction FreeLibrary pour libérer un module chargé, que le chargement du module ait ou non entraîné 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 prudent 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 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 du 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 d’accès relatif, le chemin d’accès relatif entier est ajouté à chaque jeton dans le chemin de recherche dll. Pour charger un module à partir d’un chemin relatif sans rechercher d’autres chemins, utilisez GetFullPathName pour obtenir un chemin d’accès nonrelatif et appelez LoadLibraryEx avec le chemin d’accès nonrelatif. 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 d’accès absolu.

Si lpFileName spécifie un chemin d’accès absolu et que dwFlags a la valeur 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 sans échec tant que 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 pour rechercher 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 de l’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 d’accès 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 sur lequel KB2533623 sont 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

L’exemple de code suivant illustre un appel à LoadLibraryExA.

//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;
}

Pour obtenir un exemple supplémentaire, 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.

Configuration requise

Condition requise	Valeur
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