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.
Tuesday, April 10, 2007
Wednesday, April 4, 2007
Check the Simple Things First
So today’s problem came from the Circle Cinema in Tulsa, OK. (As a side note, you have any passion for movies you should really check out this place and make a donation to help with the reconstructions http://www.circlecinema.com). As needed, I donate time and parts to the Circle to help keep things running.
A call came from the day manager at the Circle who said their ticket computer had gone “wacko” and he was wondering, needing, begging me to come by and take a look at it. Considering this computer was used to process all ticket sales, concession sales, and was also used credit card processing, I kind of understood why the manager was in a bit of a panic.
So repair procedure number one is to get from the non-technical description of “wacko” to something a little more technical about what was going on. The system was your typical HP desktop computer with Windows XP, with the only odd addition was a special touch screen monitor and point of sale software. After a little bit of Q&A over the phone, the deeper issues came to light. The computer acted hung or frozen after booting. The hard disk drive access light was flashing occasionally, the login screen was up, but when you clicked on a user account, nothing would happen. After repeated tries, the machine would eventually allow a user to login, but even after login the manager described it as incredibly sluggish.
Of course this gets your head spinning about all the others times you have seen slow PCs. Likely causes were a virus, zombie-ware, and worst case was a hard drive going bad. I know, somebody out there is saying, “a hard drive going bad, how could that make the system sluggish?” One of the warning sign of a hard drive starting to die is parts of the hard disk become unwritable. When the operating system runs out of free RAM, the OS will write a chunk of what is stored in RAM out to the hard drive (technically this is called paging). If a section of the hard drive has become damaged or just worn out, a write error will occur. The operating system will be determined to page the RAM to disk and will retry a few times and then give up, mark the this part of the hard drive as bad, and then try a new spot on the drive, wash, rinse, and repeat. All this time, the user of the computer has until the OS gets its way with the hard drive, so the system can look frozen or hung, and then suddenly come back alive when the OS finally finds a good place on the hard disk.
After driving over to the Circle, I watch and yes the computer acted just as described. The system would boot up fine, but take minutes to respond to a mouse click. You could keep clicking and clicking and then finally, something would load up. I headed back to my house to pick up some tools, disks, and a hard drive so I could make a complete backup of the system before trying to make any changes. Parting words to the manager was that it would be a good idea to find his old credit card imprint machine just in case we could not get this fixed today.
Made it home and started collecting things I might need: my laptop, a spare IDE hard drive, Ghost Boot Disk, screwdrivers, etc. This is the point where you have to appreciate the times when you get to look at a problem, and then walk away for a few minutes, because while I was gather everything up, I had a thought, “We didn’t really check the mouse”, so just to be safe, I grabbed a spare and headed back to the theatre.
After returning to the theatre, I tried my mouse theory whim, and holly crap, that was the problem. The right mouse click button on the old mouse had worn out. Like anybody standing at an elevator door hitting the button over and over thinking, this time it was making a difference. The sluggish response was simply the mouse button was only responding about every tenth click. Just to be safe, we checked the windows system event logs for disk problems and none were found. Did a spyware and virus scan and the system came back clean. Then we did a small dance because it was just a bad mouse caused by age, a spilled coke, or popcorn butter instead of something major.
Moral of the story is don’t forget to check out the simple things first before you bring out the big guns and assume it is the worst.
BK
A call came from the day manager at the Circle who said their ticket computer had gone “wacko” and he was wondering, needing, begging me to come by and take a look at it. Considering this computer was used to process all ticket sales, concession sales, and was also used credit card processing, I kind of understood why the manager was in a bit of a panic.
So repair procedure number one is to get from the non-technical description of “wacko” to something a little more technical about what was going on. The system was your typical HP desktop computer with Windows XP, with the only odd addition was a special touch screen monitor and point of sale software. After a little bit of Q&A over the phone, the deeper issues came to light. The computer acted hung or frozen after booting. The hard disk drive access light was flashing occasionally, the login screen was up, but when you clicked on a user account, nothing would happen. After repeated tries, the machine would eventually allow a user to login, but even after login the manager described it as incredibly sluggish.
Of course this gets your head spinning about all the others times you have seen slow PCs. Likely causes were a virus, zombie-ware, and worst case was a hard drive going bad. I know, somebody out there is saying, “a hard drive going bad, how could that make the system sluggish?” One of the warning sign of a hard drive starting to die is parts of the hard disk become unwritable. When the operating system runs out of free RAM, the OS will write a chunk of what is stored in RAM out to the hard drive (technically this is called paging). If a section of the hard drive has become damaged or just worn out, a write error will occur. The operating system will be determined to page the RAM to disk and will retry a few times and then give up, mark the this part of the hard drive as bad, and then try a new spot on the drive, wash, rinse, and repeat. All this time, the user of the computer has until the OS gets its way with the hard drive, so the system can look frozen or hung, and then suddenly come back alive when the OS finally finds a good place on the hard disk.
After driving over to the Circle, I watch and yes the computer acted just as described. The system would boot up fine, but take minutes to respond to a mouse click. You could keep clicking and clicking and then finally, something would load up. I headed back to my house to pick up some tools, disks, and a hard drive so I could make a complete backup of the system before trying to make any changes. Parting words to the manager was that it would be a good idea to find his old credit card imprint machine just in case we could not get this fixed today.
Made it home and started collecting things I might need: my laptop, a spare IDE hard drive, Ghost Boot Disk, screwdrivers, etc. This is the point where you have to appreciate the times when you get to look at a problem, and then walk away for a few minutes, because while I was gather everything up, I had a thought, “We didn’t really check the mouse”, so just to be safe, I grabbed a spare and headed back to the theatre.
After returning to the theatre, I tried my mouse theory whim, and holly crap, that was the problem. The right mouse click button on the old mouse had worn out. Like anybody standing at an elevator door hitting the button over and over thinking, this time it was making a difference. The sluggish response was simply the mouse button was only responding about every tenth click. Just to be safe, we checked the windows system event logs for disk problems and none were found. Did a spyware and virus scan and the system came back clean. Then we did a small dance because it was just a bad mouse caused by age, a spilled coke, or popcorn butter instead of something major.
Moral of the story is don’t forget to check out the simple things first before you bring out the big guns and assume it is the worst.
BK
Subscribe to:
Posts (Atom)