前阵子很粗略的摸过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