Home / Culture and Society / Science and Technology / Hal.dll Missing Error Killed My PC (and How I Saved Its Life)

Hal.dll Missing Error Killed My PC (and How I Saved Its Life)

Please Share...Print this pageTweet about this on TwitterShare on Facebook0Share on Google+0Pin on Pinterest0Share on Tumblr0Share on StumbleUpon0Share on Reddit0Email this to someone

I was running a routine system scan with MalwareBytes.org's Anti-Malware program, which has served me very well in the past. It found files left behind by the Vundo virus I had that Spybot, Norton, and NOD32 all missed. MBAM also didn't show any of the numerous false positives I encountered with NOD32 (which prompted me to stop using it) so it earned my trust rather quickly.

The scan finished, and it said there was a problem with my boot.ini file. Putting my trust in the program that had yet to lead me astray, I allowed it to quarantine the file. I figure, worst case, most quarantined files can be restored if it causes a problem. That's true, provided you can get to Windows and run the program that quarantined the file in the first place. This is where the trouble started.

I knew boot.ini was important, but figured Windows would/could rebuild the file during the next reboot, based loosely on our experiences here, and the significance of this event was lost on me. Rather, it was until the next day when I turned on the computer.

Rather than the usual black and white DOS-flavored nonsense, the Windows progress bar, and then my friendly login screen, all I got was a black screen with white text telling me that the computer could not start up due to a problem with my hal.dll file either being corrupt or missing entirely. That still cracks me up: is it missing or corrupt? You'd think a computer would know the difference.

A quick search revealed that this can be a quick fix, or a pain-in-the-butt fix to work through. If the hal.dll (Hardware Abstraction Layer, protects hardware, memory, etc. from malicious software) is truly well and fu…er, corrupt, you need to try to repair your Windows installation from the Windows CD, use the recovery console to manually fix it, or wipe and reinstall your whole OS. Not exactly something I was dying to do this fine afternoon, especially when I was already supposed to be working. I fiddled around with this for a while, unable to get the repair/recovery console fixes to even do anything, so I opted to look into the other methods.

The simpler fix said that sometimes hal.dll errors pop up if there's a problem with – you guessed it – your boot.ini file. Apparently Windows couldn't/didn't rebuild it after I allowed Anti-Malware to quarantine it, as it's something you need prior to Windows even starting. If I can't get to Windows to rebuild the file, DOS wouldn't even start, Safe Mode was hosed, what's a guy to do? Gut the computer, that's what.

It was a Sony VAIO SZ-series laptop, and opening the thing can be a pain largely due to its compact size (one of the things I love about it). Still, I'd done it before, so away we went with the screwdriver, and I was at the hard drive before long. The idea here was to take out the HDD, hook it up to another computer as a secondary drive, rebuild the boot.ini file on the drive manually, pop it back into the laptop, restart, and (fingers crossed) all would be well.

This is where you say, "But it's a laptop drive, silly; you can't just throw it on a regular cable in another computer, you'd need something special!" and so I do. I used this handy dandy Vantec everything-to-USB adapter I picked up at Micro Center instead of a single-use hard drive enclosure. I extracted the afflicted hard drive, connected to the appropriate SATA connector on the adapter, powered it up, plugged it into an available USB port on my girlfriend's computer, and presto: there were the drive's contents on display.

Now to the task of rebuilding the boot.ini file. There are some standard ones out there to work from, but since my original boot.ini was quarantined, I couldn't open it to see if my system had any specifics. Fortunately, my gf has almost the same laptop as I, only with Windows XP Home, whereas I have Pro. Easy enough to copy her boot.ini and edit the name of the OS it should be looking for. Things seemed ready to rock.

Popped the drive back into my laptop, closed it up, hit the power button, and got the same error, unable to start up due to a problem with hal.dll. Come on, HAL, just open those pod bay doors for me, would you?

Now granted, on a typical system, you would be finished here. The problem at this point ended up being that I had a "hidden" recovery partition that Sony likes to make on some systems. My gf's computer apparently doesn't have one, so she only has one partition, whereas I have two. Because of this, I had to bump the numbers for partition identification up to 2 instead of 1. Like this:

[operating systems]multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="Microsoft Windows XP Professional"

Instead of:

[operating systems]multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional"

It's a teeny tiny thing, but makes all the difference. This time when I fired it up, everything worked. Now that I had access to Windows and Anti-Malware again, I wanted to see what was so damn special about the previous boot.ini that it got flagged and created this whole mess to begin with.

I restored it to the original location, renamed it (just in case, so it wouldn't boot with the questionable file in case there really was something wrong with it), and opened it up in Sandboxie (again, can't be too careful). Instead of having legible command lines in plain English, it was the sort of thing you expect when you open a compiled file, all sorts of random characters, spaces, and other gibberish that makes no sense to the average human, but computers understand.

I don't know if this happened prior to the Anti-Malware scan (or more importantly, how it would have happened) or during the quarantining process, but I figured if it was bad once, it should be bad again, right? So I right-clicked the file, ran Anti-Malware specifically on it, and it came back with "No Malicious Items Found." Um, okay. So I scanned the entire computer again with the same result, no malicious items found. Weird.

I still don't know what that was all about, but I deleted the "suspect" file anyway since I'd built a working one in its stead. I still trust MBAM, though its flawless armor now has a chink in it. It's simply one more example of how even the best security software isn't perfect. Heck, if I didn't know how to repair the damage, MBAM could have effectively done more harm to my system than many of the threats it's designed to protect against.

How's that for a healthy dose of irony?

Powered by

About Mark Buckingham

  • Lesson learned again…software is not perfect. Thanks for the alert. I’m pretty cautious, usually, but We all get comfortable that our security tools know what they’re doing, so yours is an excellent lesson.

  • I found it especially troubling that after I released the “suspect” file back onto the system and re-scanned it, MBAM didn’t flag it again. Crazy fluke that almost cost me my data.

  • Tony

    I expect being a systems file boot.ini the security software reviews it once each scan for problems (not a malware check), has the boot ini being modified to load a boot loader virus? for exanple. In this case it identified it was faulty and unfortunately did not take any step other than the default quaranteen. It would do this because it detected corruption and should know better and give you advice to fix it before rebooting. A smart tool would rebuild the boot.ini automatically. Once you fixed it and did a malware scan it checked the content against it’s signature database and there was no malware, never was. Not surprising I expect if you replaced the the good file with the bad it would quarenteen it again.

    Would other tools do it better? I don’t know but yes the software could be better.

  • Bryan

    I think the reason that MBam didn’t detect a problem with the boot.ini on the second scan was because it was no longer considered a critical system file, but rather just a plain text file. Since there were no virus signatures found in it, it passed the scan. The original problem was probably just that the boot.ini became corrupted somehow so MBam detected it as a problem.