C#关于LoadLibrary的疑问详解
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
关于 LoadLibrary 的疑问
Win32 API 中 LoadLibrary 函数的功能加载某个库文件(通常 dll 文件),然后返
回 HMODULE 句柄,可以使用两个这个句柄来调用dll中的导出函数,一切似乎就
这么简单。
们考虑深入一,提出几个问题。
使用 Process Explorer 可以看到进程所加载的 dll,当然也可以看到使用LoadLibrary 函数所加载进来的 dll。
一个dll被某个进程加载后,这个dll就表现
为被占用了(不能被更改、不能删除)。
那问题就来了,LoadLibrary怎样占用一
个dll文件的呢?用CreateFile函数打的吗?们先不急着解答此问题。
更进一步们
发现,在Process Explorer 进程的handle 列表中[1]并没有发现哪个handle跟被加
载的dll相关,这个问题又跟前面的问题发生了矛盾,既然dll被占用了,为什么
不存在handle与被占用dll文件相关呢?
别急,们将会解答上面提出的两个问题。
不过在解答之前,们先个知识铺垫。
们都知道,在 Windows 中去占用一个文件最直接、最简单的就调用 CreateFile API 函
数来打文件,读者可以试着写个 Demo 使用 CreateFile 来打某个文件,打文件后,
使用 Process Explorer 就可以看到被载入文件的句柄(注意Vista、Win7中的进程
完整度级别问题)。
具体原因:CreateFile会创建一个内核对象,与被打的文件相关,Process Explorer 可以查看内核对象,当然就可以看到刚才被打的文件句柄了。
有了上面的知识铺垫,们可以始解答上述第二个问题了。
dll被载入后,为什么不
存在handle与被占用dll文件相关的问题。
仔细阅读关于 Windows 内核对象的文
档可以发现,Windows 内核对象在编码上使用 HANDLE 类型来表述的,有文件、
管道、油槽、等等,并且由 CloseHandle 函数来予以关闭。
而LoadLibrary 返回的
一个HMODULE,由 FreeLibrary 释放,其并非内核对象,而 Process Explorer 的handle列表只会显示内核对象句柄。
所以这就解释了上述的第二个问题。
LoadLibrary既然没有创建内核对象(由HANDLE来表述的对象)来占用dll文件,那它怎样将文件占用的呢?不过完全可以肯定的一,不用 CreateFile 来打的,如果
用 CreateFile 来打文件,则应该可以在 Process Explorer 列表中看到。
要解释此问题,们可以试着写个程序,然后调试到 LoadLibray 中[2],看看其究竟怎样占用dll 文件的。
经过逐步深入调试发现,LoadLibrary 最终调用 Windows DDK(Windows Driver Develop Kit)函数 ZwOpenFile 来实现文件被占用的。
具体函数调用栈信息
如下:
ntdll.dll!_ZwOpenFile@24() + 0xa bytes
ntdll.dll!_LdrpFindOrMapDll@24() + 0x2c36 bytes
ntdll.dll!_LdrpLoadDll@24() + 0x145 bytes
ntdll.dll!_LdrLoadDll@16() + 0x74 bytes
KernelBase.dll!_LoadLibraryExW@12() + 0x120 bytes
kernel32.dll!_LoadLibraryW@4() + 0x11 bytes
Te.exe!wmain(int argc, wchar_t * * argv) Line 16 + 0xd bytes C++
Te.exe!__tmainCRTStartup() Line 552 + 0x19 bytes C
Te.exe!wmainCRTStartup() Line 371 C
kernel32.dll!@BaseThreadInitThunk@12() + 0x12 bytes
ntdll.dll!___RtlUserThreadStart@8() + 0x27 bytes
ntdll.dll!__RtlUserThreadStart@8() + 0x1b bytes
ZwOpenFile 为 Windows DDK 函数,跟 CreateFile 等用户态函数不同,此函数打文件并占用之,但其不创建内核对象。
所以这就解释了,为什么使用 LoadLibrary 函数加载 dll 后,在 Process Explorer 的 handle 列表中看不到对应的 dll,而dll又被占用的原因。
简而言之,就使用了打文件函数来打文件,但此函数跟 CreateFile 不同,不会创建内核对象handle。
[1] 启 Process Explorer 的handle列表为:View à Lower Pane View à Handles
[2] 关于怎样调试进入到 Windows API 中的方法,可以查看的另一篇文章:调试Windows API。