I made a big mistake last week. My script that cleans out all caches and deletes all possible temporary files to free up as much space as possible malfunctioned. Windows did a weird thing it has done a couple of times in the past few months were the TEMP environment variable stops expanding any variables it contains, and thus pointing to an incorrect directory. It is solved simply by rebooting, but I unwisely decided to clear the caches (which is a task I often do prior to shutting down) before rebooting. When the script executed, instead of deleting the files in the temp directory, it deleted C:\, recursively. That’s right, it deleted Windows, Program Files, Documents and Settings, and everything in C:. Unfortunately I did not notice this until it had made its way through most of the drive. Fortunately, I stopped it before it got too far into the Documents and Settings folder. It managed to wipe out all files in \Windows and \Program Files that were not in use (open) which included most of Windows and the files required to boot.
Obviously the first thing to do was to NOT reboot. At that point, rebooting would have been death since most of the files required to boot were gone. I managed to keep a cool head and quickly popped in the DVD that contains the most recent PowerQuest DriveImage image of the Windows drive (which unfortunately was from 2006). I opened it with the PQIExplorer (the PQIBrowser is really, really slow when extracting files), and extracted all files from C:\ in it to C:\ making sure to click NO to the overwrite prompts. The problem was that clicking No-To-All doesn’t work and seems to just be the same as the Cancel button, which hence required clicking No (or rather pressing the N key) a whole lot of times. I actually tried using macros to automate it, but that didn’t work as expected and caused more problems. A good, simple, effective, low-tech solution was to simply place a small, heavy object on the N key to hold it down and come back in an hour.
Eventually, the drive was restored (for all intents and purposes), and it was time to chance a reboot. As expected, it did not work. Luckily I knew instantly what the problem was: the boot files were missing. Apparently I focused too much on restoring the folders and forgot the files in the root. Doh! I spent the next couple of hours trying to figure out how to use the pqiextd command line tool to extract the missing files from the image in DOS mode. I could neither find the BAT file I used last time I needed to extract files from a PQI image from the command line, nor could I view the manual since the DOS PDF viewer (Adobe Acrobat 1.0) could not open that version of PDF files. Eventually, it dawned on me to just get a copy of the files (ntldr and ntdetect.com) from the Windows install CD. That took all of five seconds and I rebooted once again.
This time, Windows actually managed to start, and even boot! I went to bed and spent the following day restoring the system as much as possible. This included removing apps that have been removed since the last backup, installing apps that were installed since then, updating some others, reinstalling some device drivers, and checking and re-updating Windows.
Amazingly enough, the system was about 80-90% restored—although some settings files are gone—in only about one day. Despite what the haters may say, Windows is surprisingly resilient and not as spaghetti-code as they make it out to be. DLL-Hell nothing, Windows managed to bounce back from near-annihilation with little effort. Let’s see OSX or *nix do that.
*UPDATE*
I updated the clearing script to prevent this from happening again. It was as simple as placing a protected dummy marker file in the temp folder’s parent, and testing for it’s existence in the script, before deleting. Nice.