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.







Article comments
1 - Eva Pintor
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.
2 - Mark Buckingham
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.
3 - 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.
4 - 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.