Some software vendors haven’t caught on yet, and still make applications that run under Windows only. Unfortunately for us, some of those apps are “must have,” so we still have to have at least one working copy of Windows around. Our current one is a refurbed off-lease IBM desktop we picked up a few years ago, running XP. It’s been up and running lately, but doesn’t do much other than installing so-called security updates from time to time.
We had left it alone for a couple of weeks while busy with other projects. Today, I tickled it a bit to wake it up, and, when the “select user” screen appeared, clicked on my username. The machine whirred a bit, then promptly announced I was being logged out. OK, idiosyncratic behavior sometimes happens, so I try again. Same thing. Different user, same thing. Hmm. Maybe something got corrupted, boot to Safe Mode. Same thing… Can’t logon, even as administrator (it’s XP Home, so, no difference, really). Oh-oh. We did have some fairly important stuff on this machine. Not good.
So, off to the Web on one of our trusty Linux boxes, symptoms indicate the C:\\WINDOWS\system32\userinit.exe file is, what? Missing? How can that happen? This is a vital system file in the middle of one of the most holy of holies in the whole operating system. But, I rummage through my files and drag out the Ubuntu 9.10 CD I used to upgrade my laptop a couple weeks ago (which had it’s own issues with wireless drivers, but nothing like casually losing an essential file after running for three or four years).
I boot the “live CD” version of Ubuntu 9.10, mount the Windows partition, and, sure enough, no userinit.exe file. Everything else seems to be there, so I boot up a newly-installed XP virtual machine running under VirtualBox on our 64-bit Linux box–to which I was planning to migrate our Windows “have to” apps. I upload the missing file to my Linux account using pscp.exe, then pull it over to the broken XP installation with scp, using the live-CD session. Next, reboot to Windows XP, and voila! it comes up normally.
Going back over the long tech forum trail, I find that this is a not-uncommon event with XP, and, if you only have Windows to work with, is painful if not nearly impossible to recover from, usually involving extracting the file from an OEM CD. We do have one (which is where our Virtual-Box installation came from), but it was much easier to do the deed by booting Linux. Besides, taking the file from a running XP installation ensures it is the latest version–there is always that issue when restoring from the original CD. Windows doesn’t have packages with dependency checking like Linux and other Unix-like systems do, so it would be easy to get out-of-spec by doing that.
Next, we did some more detective work to see why something like this would happen in the first place. Now, there isn’t a smoking gun, because these forums are run by and frequented by folks who think that Windows is the only way to compute, and that whatever it does is “normal,” so nobody thinks it is strange that this fatal bug is actually a Stupid Microsoft Trick, used in a feeble attempt to emulate Unix’ system single-user-mode and ‘NOLOGIN’ environment settings, when installing system updates. It appears that the Windows Updater actually modifies the registry under certain circumstances to perform this trick, and may replace the userinit.exe file. After all, have you ever wondered how the system does the reboot thing during an update and bypasses the logon entirely? If you are so unlucky as to try to logon to your machine during this time or–because the automated process may not go quite as smoothly due to network glitches, power events, or whatever–after the update has failed to complete correctly, you are now permanently in zero-user mode, and the file is just plain gone.
Sorry, Microsoft, a lot of us think this is just not the way to run a computer operating system. Our preferred system architecture is well-thought-out, handles multiple security levels, multiple users, multitasking, and has done so nearly flawlessly for about 40 years, during which time it just gets better. Yours has been built from a 16-bit port of an 8-bit microprocessor program loader that has been an endless series of compromises and risks to beat the clock and can’t get any better unless the legacy crutches are abandoned once and for all. No matter how fine you try to close the gap on a race condition, it is still a race condition, and sooner or later, deadlocks happen. A patched kludge is still a kludge.
Meanwhile, while working on the fix, we quietly backed up the entire hard drive onto one of the Linux servers. so our data is safe. Now, if we could only persuade the software providers to write their applications in solid code for operating systems it could actually work on safely, and we wouldn’t have to endure these kinds of torments.
Caveat–this worked for me as written, but you might have to modify more files in the system32 directory to get the machine to boot so you can fix the Registry if the logon value for the executable file has been changed. In my case, the userinit.exe file was just missing, the Registry seems to be normal. No malicious malware suspected, just a missing file that gets unsafely manipulated by updates–on purpose.