Je viens de découvrir par hasard que cela fait GetModuleHandle("ntdll.dll") fonctionne sans un appel précédent à LoadLibrary("ntdll.dll"). Cela signifie que ntdll.dll est déjà chargé dans mon processus.Les applications Win32 sont-elles automatiquement liées à ntdll.dll?
Est-il sûr de supposer que ntdll.dll sera toujours chargé sur les applications Win32, de sorte qu'un appel à LoadLibrary n'est pas nécessaire?
De MSDN on LoadLibrary() (non souligné):
Le système maintient un compte de référence par processus sur tous les modules chargés. L'appel de LoadLibrary incrémente le nombre de références. L'appel de la fonction FreeLibrary ou FreeLibraryAndExitThread décrémente le nombre de références . Le système décharge un module lorsque son compteur de référence atteint zéro ou lorsque le processus se termine (quel que soit le nombre de références ).
En d'autres termes, continuent d'appeler LoadLibrary() et assurez-vous que vous obtenez votre poignée ntdll.dll pour être sûr - mais le système sera presque certainement cognant un compte de référence comme il devrait déjà être chargé. En ce qui concerne «est-ce que c'est vraiment toujours chargé?», Voir Windows Internals on the Image Loader (la réponse courte est oui, ntdll.dll fait partie du chargeur lui-même et est toujours présent).
Le paragraphe pertinent est:
Le chargeur d'images vit dans le système en mode utilisateur DLL Ntdll.dll et non dans la bibliothèque du noyau. Par conséquent, il se comporte exactement comme un code standard faisant partie d'une DLL et il est soumis aux mêmes restrictions en termes d'accès à la mémoire et de droits de sécurité. Ce qui rend ce code spécial, c'est la garantie qu'il sera toujours présent dans le processus en cours (Ntdll.dll est toujours chargé) et qu'il est le premier morceau de code à exécuter en mode utilisateur dans le cadre d'une nouvelle application. (Lorsque le système crée le contexte initial, le compteur de programme ou le pointeur d'instruction est défini sur une fonction d'initialisation dans Ntdll.dll.)
Il s'agit d'un détail d'implémentation qui peut être modifié. Vous * devez * ne pas utiliser quoi que ce soit dans ntdll.dll directement. Mais tant que vous le faites, Microsoft ne peut vous aider que si vous le faites correctement. Il est inutile d'éviter LoadLibrary(). –
* ntdll.dll * toujours chargé dans tous les processus. cela a toujours été et sera toujours sûr – RbMm
Pensez-y de cette façon ... Vous avez appelé GetModuleHandle(). GetModuleHandle() est dans kernel32.dll, donc votre application devait lier à elle. Si vous regardez les dépendances de kernel32.dll, vous verrez qu'il dépend de ntdll.dll. Donc, si votre application doit charger kernel32, elle doit aussi charger ntdll. Mais, cela ne devrait pas être une surprise à propos de ntdll car il est la racine de tout processus Win32. Il y a plusieurs/plusieurs fonctions dans kernel32 qui sont des wrappers autour des fonctions de ntdll. –