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:
default=multi(0)disk(0)rdisk(0)partition(2)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="Microsoft Windows XP Professional"
.jpg?t=20120527181101)
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.