AMD Processors
Decrease font size
Increase font size
Topic Title: Rebase those dlls
Topic Summary:
Created On: 03/11/2005 05:05 PM
Status: Read Only
Linear : Threading : Single : Branch
Search Topic Search Topic
Topic Tools Topic Tools
View similar topics View similar topics
View topic in raw text format. Print this topic.
 03/11/2005 05:05 PM
User is offline View Users Profile Print this message

Author Icon

Posts: 87
Joined: 10/06/2003

Ever heard of rebasing? Well you should have, especially if you're short on memory or just want your system to run faster.

First some explanation. Once of the neat things about Windows is its ability to share code between running programs. It does this through the use of dlls. You can recognize them normally by their extension - .dll.

Every dll has a preferred load address - where it loads in virtual memory. If that address is available it will load into memory there and if it is paged out of physical memory it will be reloaded direct from the image on the disk. Every program that uses that dll will use the same memory.

But what if that address isn't available? Then it has to be relocated. The OS loader goes through the dll loaded into the new memory location and "fixes up" the all the absolute addresses. Unfortunately the memory image now doesn't match the disk image so the loader writes the new image to the pagefile and uses that for paging. Every program that loads the dll at a "wrong" address has, in effect, its own private copy of the dll and they cannot be shared. Result? You use a lot of pagefile, a lot more memory and you poison the processor cache.

There a MSoft explanation here:' ">

How do you know which of your dlls have been relocated? Use this utility:' ">

and run it from a dos window with the r option like this:

listdlls -r

You can also see the default load address for a dll using depends.exe.

How bad is the problem? Well a lot of MSoft dlls have not been properly set up. The newest MSoft installer has a 3MB msi.dll which trys to load at a system default location - 0x10000000. With just Outlook & my normal background tasks running I had 6 copies of it at different address - 18MB of virtual/pagefile in use and swapped in/out on every switch. Every MSoft office program loads msi.dll The Logitech keyboard driver also trys to hook at 0x10000000 so that was private to each app and linked into every app.

So how to sort it out. There's a MSoft tool called rebase.exe that comes with Visual C++ and the free SDK - you may find it elsewhere. You can set the default load address from a dos window like this:

rebase -b 0x660000000 xxx.dll

Generally rebase in the 0x60000000-0x68000000 range.

Rebase won't work if the file is in use so you often have to do this in safe mode. Get available addresses using that listdlls utility.

One note - about msi.dll. Its always in use, even in safe mode. So make a copy and rebase the copy. Now go into safe mode command prompt and copy the relocated version from the command line ( I rebased mine at 0x62b00000).

Do a google on rebase memory and you'll find lots of articles.

 05/15/2007 02:48 PM
User is offline View Users Profile Print this message

Author Icon

Posts: 87
Joined: 10/06/2003

Another tip: What if the offending (relocated) dll is in use even if you boot into safe mode with command prompt?

You can use the move command to put the dll into another directory - EVEN WHEN ITS IN USE.

Example, you want to rebase the system file rsabase.dll which is used by the winlogon process.

From windows, dos window:

copy \winnt\system32\rsabase.dll \temp (just some temporary directory)
cd \temp
rebase -b 0x7ca30000 rsabase.dll

Now boot into safe mode with command prompt. From the command line:

cd \winnt\system32
move rsabase.dll \ (place the running file into the root directory)
copy \temp\rsabase.dll (put the rebased file into the system directory)

Now reboot into windows and the system file will be loaded from the \winnt\system32 directory and based at the new location without being relocated.
112018 users are registered to the AMD Processors forum.
There are currently 0 users logged in.

FuseTalk Hosting Executive Plan v3.2 - © 1999-2014 FuseTalk Inc. All rights reserved.

Contact AMD Terms and Conditions ©2007 Advanced Micro Devices, Inc. Privacy Trademark information