如果我想重新綁定我的DLL，我該如何去做呢？

Question

這是this question的延續。

我正在測試重新綁定.NET DLL，並且NGENning它們會在終端服務器上爲我提供更多共享代碼。

但是，我的計劃似乎有一個缺陷，這是我似乎無法找到一個工作方法來找出一組工作地址。

我想我可以做如下：

1. 簡單的建造和NGEN一切
2. 啓動程序，確保所有的DLL已經加載
3. 使用LISTDLLS/R PROGRAMNAME獲得正在運行的實例的當前使用中的地址列表
4. 使用那些已重新映射的DLL的地址作爲這些dll的新基址地址
5. UN-NGEN everything，and開始回到1

然而，這卻變成了Schrödinger鍛鍊，因爲基礎重建某些DLL顯然要麼改變加載順序或如何操作系統搬遷其他DLL的行爲。例如，假設在初始運行後，我有一個列表，說明DLL A，B和C需要在地址1000,2000和3000處。沒有提到DLL D，E和F，它們也是同一個系統的一部分。據推測這些是在他們目前的baseaddress加載，否則我會假設LISTDLLS會告訴我這件事。

所以我改變A，B，C的地址，重複一切，現在DLL C，D和E已經重新定位。 A和B現在好了，現在E和F已經搬遷了，C仍然在被拖動。

我意識到這個練習有些徒勞無功，因爲不管我在我的機器上發現什麼，在目標終端服務器上使用並注入的DLL可能會打擾這個畫面，但我認爲如果我至少能夠確定某些DLL可能位於其指定的基地址，那麼同一程序的多個實例之間的共享代碼量將會增加。只是說，只是爲了沒有必要「提醒」我:)

由於我們所有DLL的原始基地址是默認的，這意味着每個DLL（可能除了第一個加載的）都被重新定位，因此映射到頁面文件，我會認爲會有一個潛在的收益高於0.

有什麼建議嗎？

Answer 1

您可以使用DUMPBIN（位於Visual Studio中）找出DLL首選加載地址和內存範圍，並根據這些數字進行規劃。

DUMPBIN /頭會給你：

7DC90000 image base (7DC90000 to 7DD5FFFF) 

如果按照首選加載地址規劃，你應該沒有問題。