前陣子很粗略的摸過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