Tuesday, April 10, 2007

Illegal System DLL Relocation

So today’s odd problem comes from helping my friend Melinda. Originally, I was at her house updating her child’s computer from Windows ME to XP. So while I was loading all the secondary software like virus scanning and DVD burning software, Melinda brings me her laptop and says, “I swear I didn’t do anything to cause this!” On her screen is a big windows dialog box with the message, “The system DLL user32.dll was relocated in memory. The application will not run properly. The relocation occurred because the DLL C:\Windows\System32\Hhctrl.ocx occupied an address range reserved for Windows system DLLs. The vendor supplying the DLL should be contacted for a new DLL.”

I have to say that was a new one. So I started by finding HHCTRL.OCX and see if the vendor was listed in the controls properties and noticed it was signed and published by Microsoft. Looking at the title bar of the error message, the application RTKHDCTL was listed as the application, and a little researched showed this was part of the Realtek Audio driver.
As a simple test, I uninstalled the Realtek audio driver using the Add/Remove Program. Reboot and the error message did not return. Because most people really do want sound on their laptop, from the Device Manager, I right clicked and reinstalled the device allowing Device Manager to install the latest driver from Windows Update. On the next reboot the error message returned. Hmm, since everything was Microsoft blessed, the next stop was http://support.microsoft.com/. A simple search there proved Melinda was not alone in her error message and it really wasn’t her fault.

It seems the problem was caused when Microsoft issues two security patches for XP, 925902 (MS07-017) and 928843 (MS07-008). The Hhctrl.ocx file that is included in security update 928843 has a conflicting base address with the User32.dll file that is included in security update 925902.

Ok, so what is a conflicting base address? Base addresses are part of the fun of writing program library and dynamically loading them into memory. When authoring a DLL (Dynamically Linked Library), you give the compiler some memory address which the compiler will make the compiled library’s base loading address. Another way of looking at this would be if the library was loaded somewhere in your computer’s memory, what would be the first memory address of the first byte of your library. All the code execution statements that need to jump to a new memory address and data being accessed are then determined relative to this base starting memory address.

During program execution, is when the DLL is actually loaded into RAM, if the memory you gave the compiler as your base address in free, the library loads into RAM and is ready to use. If the memory address range you gave during compilation is not free, then the loader must first load the library into memory, and then alter the memory addresses in the code that used an absolute address and change them to the new location. Nothing really bad about doing that, but it does take time to scan through the code and make all the changes. So part of being a good developer is picking a good base address that would rarely, if ever be in use.

So getting back to Melinda’s laptop, the solution was simple. Microsoft had issued a hotfix which corrects the conflict in memory base address. If you are having this problem, check out Article 935448 at http://support.microsoft.com/, where you will find the hotfix that will fix your PC like it did Melinda’s.