1

这是这个问题的延续。

我正在测试是否对 .NET DLL 进行变基，NGENning 它们是否会在终端服务器的内存中为我提供更多共享代码。

但是，我的计划似乎有一个缺陷，我似乎无法找到一种工作方法来找出一组工作地址。

我认为我可以做的如下：

  1. 只需构建和 NGEN 一切
  2. 启动程序，确保所有 DLL 都已加载
  3. 使用LISTDLLS /R PROGRAMNAME 获取正在运行的实例的当前使用地址列表
  4. 使用重新映射的那些 DLL 的地址作为这些 dll 的新基地址
  5. UN-NGEN 一切，从 1 开始

然而，这已经变成了薛定谔的练习，因为重新定位某些 DLL 的行为显然会改变加载顺序或操作系统重新定位其他 DLL 的方式。

例如，假设在初始运行后，我有一个列表，说明 DLL A、B 和 C 需要位于地址 1000、2000 和 3000。没有提及 DLL D、E 和 F，它们也是同一个系统。大概这些是在它们当前的基地址加载的，否则我会假设 LISTDLLS 会告诉我这一点。

所以我改变了A、B、C的地址，重复一切，现在DLL C、D和E已经被重新定位。A和B现在都好了，E和F现在搬家了，C还在被洗牌。

我意识到这个练习有点徒劳，因为不管我在我的机器上发现了什么，在目标终端服务器上使用和注入的 DLL 可能会干扰这张图片，但我认为如果我至少可以确保一些DLL 可以位于其规定的基地址，然后同一程序的多个实例之间的共享代码量会增加。只是说，只是为了没有必要“提醒”我:)

由于我们所有 DLL 的原始基地址是默认值，这意味着每个 DLL（可能除了第一个加载的）都被重新定位，因此映射到页面文件，我认为可能会有高于 0 的增益。

有什么建议吗？

4

1 回答 1

1

您可以使用 DUMPBIN（包含在 Visual Studio 中）找出 DLL 的首选加载地址和内存范围，并根据这些数字进行规划。

dumpbin /headers 会给你：

 7DC90000 image base (7DC90000 to 7DD5FFFF)

如果您根据首选装载地址进行计划，则应该没有问题。

于 2009-02-18T00:50:16.970 回答