In a previous post, I mentioned having to wipe clean a customer’s drive to repair virus damage.  It turns out that the customer was unable to locate the recovery disks that came with the machine, and since it was a special version operating system (which means we didn’t have copies of it ourselves) and the customer shouldn’t have to wait until after Christmas for us to order recovery discs, I decided to manually repair the system.

The first step was actually handled for me – the customer was referred to us through one of our link exchange partners in San Diego. Kurt Rein of Mobile Computer Wizard had e-mailed our customer with an idea of the problem, and it was subsequently shared with us. Kurt had blogged about a problem matching the symptoms we noticed, so I decided it was worth a shot. The problem: Logon, then immediate logoff, preventing the user from entering the system (even in Safe Mode).

The first step was popping the drive out of the customer’s machine and scanning it thoroughly for viruses, malware, trojans, and spyware. It had tons. Next was figuring out what was preventing the successful logon. I had a leg-up here, as Kurt had suggested a direction to head. His posting, found here, attributed the trouble to a missing userinit.exe file under the Windows system folder. Further searching the web for additional information, I found there were many different methods for addressing the issue, and positive results were achieved by all of them (to some degree or another).

So with the drive out, I removed the malware I could (some of it wasn’t detected due to the fact it wasn’t the primary boot drive), reinstalled the drive back into its machine, and proceeded to try the first suggestion (here): Use the Windows XP Recovery Console to overwrite the potentially corrupt userinit.exe file.

It didn’t work. When XP loaded, login resulted in logoff right away.  The file was fine, it appears the registry entry for the file location was corrupted or changed from the original “factory” entry. One solution down.

Okay, next suggestion (here) was to manually edit the registry, but it had to be done remotely since there was no way to do it locally (it booted, but wouldn’t log in, remember?). Using the functionality built in to Windows networking, I could remotely edit a registry across a network. Cool!

It didn’t work. Again. Why? Because the network card had been disabled in Windows, and I couldn’t edit the registry to enable it. UGH! Foiled again!

You know what they say – third time’s a charm! Using the suggestion found here, I decided to use a “virtual environment”, or “physical environment” disk to load a hybrid O/S that would allow me to load the registry and make physical changes. Some trial and error taught me to “slipstream” the disk controller drivers into the BartPE disk in order to access the primary drive, and the rest was all according to the steps in the aforementioned post. I was able to edit the registry by loading the correct hive, correcting the registry key that linked to a false file, then unloading the hive and exiting.

It took LOTS of time, and quite an effort to sift through the misinformation and misdirection, but the machine is (almost) just as it was before the infection. While it’s always helpful to have a guide to work from, it’s more important to use common sense and work through the easiest and least damaging repair before attempting the difficult and potentially more harmful solution.