Question

I've got a small test solution with one exe and three Dlls, the exe calling the three Dlls once each. I've set the Build->Advanced->DLL Base Address setting to 0x41000000, 0x42000000 and 0x43000000 for Dll1.dll, Dll2.dll and Dll3.dll respectively. I've run

ngen install ConsoleApplication1.exe

and this has successfully ngen'd the application along with the three Dlls. I didn't really want to ngen the exe but so far this is the only way to produce any results at all.

At runtime I use VMMap to monitor the virtual address space and it reveals that the ngen'd Dlls are sitting within a consistant range of virtual memory, however they are still jumping around within that range, loading at a slightly differnt address every time I run them. VMMap reveals that there is nothing allocated at the addresses where I'm trying to load the images, so this jumpy behaviour is not being caused by address collisions.

I've been keeping logs:

   Dll1       Dll2       Dll3
0x40140000 0x411D0000 0x42810000 
0x40580000 0x41EB0000 0x426B0000 
0x40190000 0x41FB0000 0x42380000 
0x40F30000 0x41FD0000 0x42050000 
0x409B0000 0x41BF0000 0x42910000 
0x408E0000 0x41860000 0x42050000 
0x40B50000 0x41280000 0x42A80000

Notice that the first two digits of the address remain consistant for all three Dlls across all runs.

My actual question: Is this an indicator of success? I'm a bit confused because I thought the Dlls were going to be sitting exactly at 0x41000000, 0x42000000 and 0x43000000. The results show that they hang around that area, but never actually sit where I asked them to sit. My understanding is that you want the Dlls to be loaded exactly at the address you ask them to so that they don't have to undergo the expensive rebasing operation (which is very very expensive when your Dlls have been ngen'd). But, isn't this exactly what's happening? Sure, my Dlls are hanging around in a certain area, but they aren't sitting exactly where I asked them to sit, so surely the expensive rebasing operation is being peformed at each run time? This is exactly what I wanted to avoid.

Note: I'm not interested in arguments for/against rebasing and ngen. I just want to know what's going on and how to get it working.

Cheers SO!

Was it helpful?

Solution

Could be ASLR (addres space layout randomization) - check out links from http://social.msdn.microsoft.com/Forums/en/vcgeneral/thread/bac7e300-f3df-4087-9c4b-847880d625ad

OTHER TIPS

Doesn't the NGEN tool restrict specifying a base address for the binary image it makes for an assembly. Afaik you have to compile the “preferred base address” into the assembly itself. http://msdn.microsoft.com/en-us/magazine/cc163610.aspx

Edit *

However, if the loader cannot place the module at the desired address (because it overlaps with another module or piece of data already loaded or allocated), the module is rebased, meaning it is loaded at some other address. This implies that all addresses within the executable image need to be fixed up.

Also looking at the internet it seems many developers wish for this feature but the problem is reserving base addresses that dont conflict with other developers assembly's. What other DLLs are sitting at the addresses you expected yours to be at?

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top