2017-04-25 89 views
3

我刚刚偶然发现这样做GetModuleHandle("ntdll.dll")没有以前拨打LoadLibrary("ntdll.dll")工作。Win32应用程序是否自动链接到ntdll.dll?

这意味着ntdll.dll已加载到我的过程中。

可以安全地假设ntdll.dll将永远在Win32应用程序中加载,因此不需要拨打LoadLibrary

+3

它是一个实施细节可能会发生变化。你应该*不要直接在ntdll.dll中使用任何东西。但只要你这样做,如果你正确地做到这一点,微软只能帮助你。避免LoadLibrary()没有意义。 –

+0

* ntdll.dll *始终在所有进程中加载​​。它始终如一,永远都会肯定 – RbMm

+1

这样想想...你打电话给GetModuleHandle()。 GetModuleHandle()在kernel32.dll中,所以你的应用程序必须链接到它。如果你看看kernel32.dll的依赖关系,你会发现它依赖于ntdll.dll。所以,如果您的应用程序必须加载kernel32,那么它也必须加载ntdll。但是,作为任何Win32进程的根源,ntdll应该不会感到意外。 kernel32中有几个/许多函数是在ntdll函数中进行封装的。 –

回答

5

MSDN on LoadLibrary()(重点煤矿):

系统维护上的所有加载模块 每个进程的引用计数。调用LoadLibrary会增加引用计数。调用 FreeLibrary或FreeLibraryAndExitThread函数减少 引用计数。当其参考计数为 达到零或过程终止时(不管参考计数是多少),系统将卸载该模块。

换句话说,继续调用LoadLibrary(),并确保您得到您的句柄ntdll.dll是安全的 - 但系统将几乎肯定会撞上一个引用计数,因为它应该已经被加载。

至于“是否真的总是加载?”,请参见Windows Internals on the Image Loader(简短答案是肯定的,ntdll.dll是加载程序本身的一部分并始终存在)。

有关段落是:

图像装载机住在用户模式的系统DLL 的Ntdll.dll而不是在内核库。因此,它的行为就像是属于DLL的标准代码一样,并且在内存访问和安全权限方面受到同样的限制。是什么让这段代码更加特别是它在运行过程中始终存在的保证(Ntdll.dll始终加载),并且它是在用户模式下作为新应用程序的一部分运行的第一部分代码。 (当系统建立初始上下文时,程序计数器或指令指针被设置为Ntdll.dll中的初始化函数。)

相关问题