前陣子很粗略的摸過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/m.aspx?n=bbs/C_and_CPP/M.1509904764.A.EEA.html ※ 編輯: steve8625 (220.141.162.158), 11/06/2017 02:02:50