Question

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.

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:

1. Just build and NGEN everything
2. Start the program, ensuring all the DLL’s have been loaded
3. Use LISTDLLS /R PROGRAMNAME to get a list of current in-use addresses for the running instance
4. Use the addresses of those DLL’s that was remapped as the new base-address for those dll’s
5. UN-NGEN everything, and start back at 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.

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.

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.

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 🙂

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.

Any advice?

Answer 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 /headers would give you:

 7DC90000 image base (7DC90000 to 7DD5FFFF) 

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