如果我想重新定义我的DLL，我该怎么做呢？

This is a continuation of this question.

这是这个问题的延续。

I'm in the process of testing whether rebasing the .NET DLLs, and NGENning them will provide me with more shared code in memory on terminal servers.

我正在测试是否重新定义.NET DLL,并且NGENning它们将在终端服务器的内存中为我提供更多的共享代码。

However, my plan seems to have a flaw, and it's that I seem unable to find a working method to figure out a working set of addresses.

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

What I thought I could do was as follows:

我认为我能做的如下:

Just build and NGEN everything

只需构建和NGEN一切

Start the program, ensuring all the DLL's have been loaded

启动程序,确保已加载所有DLL

Use LISTDLLS /R PROGRAMNAME to get a list of current in-use addresses for the running instance

使用LISTDLLS / R PROGRAMNAME获取正在运行的实例的当前正在使用的地址列表

Use the addresses of those DLL's that was remapped as the new base-address for those dll's

使用重新映射的那些DLL的地址作为这些dll的新基址

UN-NGEN everything, and start back at 1

UN-NGEN的一切,从1开始

However, this has turned into a Schrödinger exercise because the act of rebasing some DLLs apparently either change the load order or how the operating system relocates other DLLs.

然而,这已经变成了Schrödinger练习,因为重新定义一些DLL的行为显然要么改变加载顺序,要么改变操作系统如何重定位其他DLL。

For instance, let's say that after the initial run I have a list that says that DLLs A, B and C needs to be at address 1000, 2000 and 3000. There's no mention of DLL D, E and F, which are also part of the same system. Presumably these were loaded at their current baseaddress, otherwise I would assume LISTDLLS would tell me about that.

例如,假设在初始运行之后我有一个列表,表明DLL A,B和C需要位于地址1000,2000和3000.没有提到DLL D,E和F,它们也是同一系统。据推测,这些都装在他们当前的基地上,否则我会假设LISTDLLS会告诉我这件事。

So I change the address of A, B, C, repeat everything, and now DLL C, D and E have been relocated. A and B are now OK, E and F now became relocated, and C is still being shuffled around.

所以我改变了A,B,C的地址,重复所有内容,现在已经重新定位了DLL C,D和E. A和B现在都没问题,E和F现在已经重新安置了,C仍然在洗牌。

I realize that this exercise is somewhat a futile one, since regardless of what I figure out on my machine, DLLs being used and injected on the target terminal server might disturb this picture but I thought that if I could at least make sure some of the DLLs could be located at their prescribed base address then the amount of shared code between multiple instances of the same program would go up. Just saying, just so that there is no need to "remind" me of that :)

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

Since the original base addresses of all our DLLs was the default, which meant every DLL (possibly except the first one loaded) was relocated, and thus mapped to the page file, I would think that there would be a potential gain above 0.

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

Any advice?

1 个解决方案

#1

You can find out a DLLs preferred loading address and memory ranges using DUMPBIN (comes within Visual Studio) and do your planning based on those numbers.

您可以使用DUMPBIN(在Visual Studio中)找到DLL首选加载地址和内存范围,并根据这些数字进行规划。

dumpbin /headers would give you:

dumpbin / headers会给你:

 7DC90000 image base (7DC90000 to 7DD5FFFF)

If you plan according to preferred loading addresses you should have no problems.

如果您根据首选加载地址进行规划,则应该没有问题。

#1