前阵子很粗略的摸过DLL import和dependency walker 我试着简单回答看看 不会讲的太复杂 （毕竟也只是要知道怎麽用XD） 若有错再请大家协助 要知道怎麽发挥dependency walker的威力 可能需要知道一点PE的运作(portable executable，其实就是exe，dll那些）会比较清楚 很简单的来说 一只PE要使用DLL内的function主要可以透过两类方式 一种是在编译/连结期 透过提供.lib 让PE与该模组作static link 这样子PE就会知道在load time的时候知道哪些module该被引入 而需要透过这个作法被引入的function会被纪录在PE的import table内 你可以试着用PE Internals这类的tool打开exe来看看import table有哪些东西 有趣的是 有时候除了import table 还可以看到另一个表 叫做delay load import table 这些function一样也是在编译/连结时透过.lib作static link的 只是他们是在真正被呼叫的时候才会被引入 dependency walker最基本的运作原理主要就是parse这只PE档的table 它尝试使用loader的工作方式来找出哪些模组会被load起来 并透过实作windows找DLL的顺序和方式来找到windows可能使用的DLL版本（有时会错） 但他终究不是loader 就你的范例而言 DllImport其实是一种run-time使用DLL的方式 LoadLibrary(), GetProcAddress()等也属此类 而因为dependency walker不是loader 他只会查表找而不会执行到dllimport这段 所以他其实并不清楚这只PE需要你范例中创造出来的那只DLL 然而这也不是完全无解 dependency walker在2.0後加入了一个叫做 application profiling的功能 简单的来说 就是先让这只PE load起来 再去监控这只PE在load的时候实际上到底找了哪些module 引入哪些function 详细的使用方式和原理作法可以参考它的说明 http://www.dependencywalker.com/help/html/application_profiling.htm 我手上暂时没有windows 所以没有实际玩过一遍你提供的范例 但就我先前经验 使用了这个方法之後 就「比较有机会」能知道到底在run-time时还会额外使用哪些DLL 以及他们到底在不在系统内 但毕竟dependency walker只是一个跟着loader行为操作一遍的工具 实际上仍可能出现和loader行为有落差的地方 这就要真的跑跑看才知道 你也可以用sysinternals的ListDLLs来看一个process到底load了哪些DLL 但我想这跟你提到希望「检查」的部份有些出入 毕竟这要能跑起来 就顺便当作参考吧 当然 反过来说 你也可以试着让原先的DLL用static link的方式跟PE连结 （先调整build DLL的选项让他build出.lib 在PE使用到的部份引入.h 专案连结.lib） 这个时候再跑dependency walker 即便不进application profiling 也应该可以找到这只DLL不见了 其实我觉得dependency walker的网站写的算满清楚的啦 用之前其实可以先参考看看 个人认为还满有价值的 附上dependency walker针对不同dependency的支援状态和一些名词定义 http://www.dependencywalker.com/help/html/dependency_types.htm 其实前文所述也只是这个页面的一点简单翻译啦 供你参考XD --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 220.141.162.158 ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/C_and_CPP/M.1509904764.A.EEA.html ※ 编辑: steve8625 (220.141.162.158), 11/06/2017 02:02:50