We like to imagine that every OS installation will work just as well as the vendor promises. When things don’t work out, identifying and remedying the case of failure can be time consuming and frustrating. This lesson in “how to determine why Windows 7 didn’t install” may help you troubleshoot a problem of your own – and save you from a Lost Weekend.
Over the past 13 months—that is, starting in March, 2009, when I began work on a book entitled Windows 7 in Depth—I’ve worked more or less constantly with Windows 7 across all of its versions. Because my responsibilities on the book included the OS install and configuration chapters, I probably installed Windows 7 over 200 times just for that project alone (it ended in July, and the book appeared in August). Since then, I’ve installed the OS at least another 200 times for other projects and tests, including various netbooks (Asus, Dell, MSI, and so forth), notebooks (Dell, HP, Asus, Acer, MSI, etc.), desktops (Dell, HP, Asus, and Velocity Micro, plus numerous DIY systems put together from components). Until a couple of weeks ago, I never encountered a single problem that stopped me from installing Windows 7 itself.
But when I decided it was time to switch my primary test system over from Windows 7 Ultimate x86 (32-bit) to Windows 7 Professional x64, I ran straight into a brick wall. See Table 1 near the end of this story for a detailed description of its initial and final components, plus other components I tried, as I worked my way through problem diagnosis and repair. In this article, I describe the sequence of events that occurred, explain how I finally diagnosed and fixed my problem, describe the vendor’s response to my problem report, and then meditate on what I learned through sheer dint of effort while working through this incident. My hope is that others can benefit from my experience without necessarily making the same missteps that I made along the path from problem discovery to diagnosis to ultimate solution.
I started my adventure using Microsoft’s excellent Windows 7 USB DVD Download Tool, combined with an ISO for Windows 7 Professional x64 that I downloaded from MSDN thanks to my Premium subscription to that service. This tool can build a bootable DVD or USB Flash Drive (UFD) using its own built-in smarts and the ISO file that you supply for it to use as the target for an install image. Under the hood, the tool uses the Windows Pre-installation Environment, aka WinPE, to build a bootable installer. (It also doubles quite nicely as a repair tool, when you can’t get your hard disk based version of Windows 7 to boot, for whatever reason.) I chose the UFD option because it’s faster than the DVD version, probably because it’s quicker to access flash memory chips than spinning optical media.
Having built the proper UFD, I restarted my test machine, then tweaked the BIOS so I could boot from that device. In under a minute I was into the Windows 7 install process. Alas, in under two minutes that install was dead in the water.
When you start installing Windows 7 you begin by watching the WinPE environment come up. You see a Vista-like progress bar while a stripped down Windows kernel loads, so that it can manage the install process on your PC. Then you work through a couple of initial install screens (the initial screen asks for your language, time and currency format, keyboard or input method, after which you must either click “Install now” or elect the “Repair your computer” option instead—this is all nicely depicted on Sean Sexton’s “Sean’s Stuff” website if you want to follow along as you read this story). After that, you agree to the EULA and specify an upgrade or a Custom (Advanced) installation.
I chose Custom (Advanced) because if you’re switching from 32- to 64-bit Windows, you have to perform what Windows-heads like to call a “clean install,” which basically means replacing whatever Windows installations are present on the drive. In fact, this being a test machine, I also used the advanced drive options on the next screen (“Where do you want to install Windows?”) to delete all partitions on my target system drive, and then built a new set of partitions to house my equally new Windows 7 installation. All this usually takes less than 60 seconds to complete, once the initial select language screen appears. Next up comes a screen that tracks progress for the installation process:
First, Windows 7 copies all the compressed files from the installer onto the target drive, then it begins to decompress (expand) those files so it can use them to perform the installation process. This is where my installation hung every time I tried it. I worked through somewhere between 20 and 40 additional installation attempts on my test machine before achieving a fix. For some reason, the installer couldn’t get past expanding files, and it would hang somewhere between 42% and 62% complete (one time it got as far as 94%, leading to the false hope that “it might just work!”). Obviously, something in my system was causing the installer to hang, but what could that be?
Banging My Head Against the Wall, Because It Feels So Good When I Stop
My initial thought was that some kind of glitch in the ISO image simply hosed the installation. It takes about 15 minutes to rebuild a new UFD from an ISO file using the Microsoft tool mentioned earlier, so that’s what I did. But when I re-ran the installation, it hung during the expanding files phase once again, and I had to decide what to do next. I tried the UFD on a different test machine (one already running Windows 7 Professional x64 successfully) with the simple expedient of slapping in a new drive in place of the existing system drive, and the process completed without a single hitch. Obviously something specific to the “problem PC” was the culprit.
That’s when I started trying BIOS variations, thinking that my recent tinkering might be borking the installation process. I ended up using factory defaults, with only a few minor tweaks to let me use my USB mouse and keyboard during the install process. I repeated that action at least half-a-dozen times, observing that while the install always hung during expanding files, it seldom hung at exactly the same completion percentage value (though 61% and 62% emerged as “favorites” over time). This took me to between 10 and 11 PM on my first day working on this project, at which point fatigue, plus family and work responsibilities for the following day kicked in and I knocked off for the night.
Working Through the Possibilities
After having slept on my situation, I decided it was time to change out some components in the problem PC. Because I’d recently been through some serious BIOS shenanigans on that computer’s Asus P5EQ3 motherboard, I immediately jumped to the conclusion that the motherboard was at fault, and should be replaced. Thereupon, I ordered a replacement—an Asus P5E3 Professional, a somewhat simpler remake of the P5EQ3 already present in the test machine, but with newer chipset and a simpler layout—so that I could rid myself of what I perceived as the obvious culprit.
Three days later, UPS delivered the P5E3 Pro to my door, on a Friday. The next morning, I jumped out of bed at an earlier-than-usual time to give myself the opportunity to tear out the old and insert the new motherboard. This took somewhere between 60 and 90 minutes, after which I inserted the UFD, fired up the computer, and once again resumed the Windows 7 installation process. To my utter astonishment and despair, the installation got to the expanding files phase and hung again. Obviously, my problem was not the motherboard.
That’s when I decided it was time to do some serious and systematic troubleshooting. I thought to test all of the major system components until I finally hit upon the real culprit. I then proceeded to isolate and replace every major system component, to see where the problem originated. Depending on how much rebuilding was involved between components, it took me anywhere from one to three hours between test runs to eliminate possible sources of my troubles. Here’s the order I followed in going through these motions, having unequivocally eliminated the motherboard as the source of the difficulty:
- Memory: a regular culprit when chasing down odd system behavior, I switched the Super Talent DDR3-1600 2 GB modules for some older, and well-tried and trusted Super Talent DDR3-1066 1 GB modules instead. No change.
- Hard disk: I swapped the Seagate 7200.11 320 and 400 GB drives I’d been using for a WD VelociRaptor 300 GB and later, a Samsung Spinpoint 1 TB 7200 RPM drive. Still no alteration in the problem.
- Graphics card: I ditched the Nvidia 8800 GT I’d had installed in the machine for a fanless Nvidia 9600 resident in my other P5K test machine. Nothing doing.
- Cables: I switched out all the removable cables in the system for brand-new cables still in their sealed plastic bags from my box of motherboard spares. Same hang.
- Power Supply: I ran the Newegg PSU calculator: it said I needed 612 Watts for my system as configured. I was using a nice little Antec 400 Earthwatts PSU (oops!), so I ran down to Fry’s and picked up a Thermaltake 650W 80-plus model for about $100. Again, it hung at “expanding files.”
- Case: Reasoning that a short in the case might be causing my problem, I yanked all of the innards out of the Antec Nine Hundred in which they were housed and rebuilt the system on an open bench case (framework, really) I often use when benchmarking components for Tom’s Hardware. Same problem all over again.
The Culprit Finally Apprehended
At this point, there was one and only one component of my system I hadn’t swapped out, mostly because I didn’t have a spare quad-core 775 LGA CPU laying around. So, after researching my options and talking with my good buddy and fellow Tom’s Hardware contributor Tom Soderstrom, I ordered a newer mid-range Q9400 processor. Another three day break from troubleshooting occurred, and I managed to get some other work done, while once again waiting for the UPS guy to ring my doorbell and drop off my latest prize.
It was with fear and trembling that I unpacked the Q9400 from its retail packaging to rip out the QX9650 and replace it with this newest acquisition under the Zalman CNPS9500 I use as the cooler for this build. Fortunately for me, a long-barreled magnetic screwdriver let me gain access to the cooler’s hold-down screws, and its drop-in package made the CPU swap both quick and easy.
Within 40 minutes of receiving the new CPU, I was running the Windows 7 Pro x64 install UFD. The biggest time waster turned out to be cleaning off the Arctic Silver thermal paste I got on my fingers while removing the old QX9650. I watched the percentages climb during the ”expanding files” stage with fingers crossed and hopes high. As the number hit 100% and the install program switched over to the next phase of the process (Installing features), I heaved a huge sigh of relief and readied my license key for the next step of this seemingly interminable adventure in troubleshooting. “I’ve got it fixed!” I announced to my wife, Dina, when I ran into the kitchen to tell her my troubles were behind me.
Table 1: Pieces and Parts in This Tale of Two Systems
The Initial column identifies what was in the system to begin with, the Tried column identifies what other elements were tried as replacements, and the Final column names what is now in the stable current configuration.
|Case||Antec 900||bench case||Antec 900|
|Power Supply||Antec Earthwatts 400||CoolerMaster GX650W||CoolerMaster GX650W|
|Graphics Card||Nvidia 8800GT||Nvidia 9600GT||Nvidia 9600 GT|
|CPU||Intel QX9650||Intel Q9400||Intel Q9400|
|Mobo||Asus P5Q3||Asus P5E3 Pro||Asus P5E3 Pro|
|RAM||SuperTalent 2x2GB DDR3-1600||SuperTalent 2x2GB DDR3-1066||SuperTalent 2x2GB DDR3-1600|
|System drive||Seagate 7200.11 320 GB||WD VelociRaptor 300, Samsung SpinPoint F11 HD103UJ 1 TB||VelociRaptor|
|Cables||Old||New (from shrinkwrap)||New|
I Should Have Known Better…
In switching from the old Asus to the new Asus motherboard, however, I’d neglected to research the BIOS settings thoroughly. Once I got the install completed, I once again found myself the victim of multiple crashes, during the post-installation phase where Windows Update catches the static OS image from the ISO up with all the latest updates and fixes. Alas, when you crash while applying updates, you’re better off blowing away the install and starting over, so I got to go through three more installs that evening before the witching hour brought another troubleshooting marathon to a close. My first panicked diagnosis was “Gremlins!” but of course I knew that couldn’t be the case…
When I got up the next morning, I answered my question “Why is the system so unstable?” when I checked the BIOS settings and found the Asus AI Tweaker turned on by default in the P5E3 Pro. Because I installed DDR3-1600 memory, the tweaker pushed the FSB speed up to 400 MHz to match that speed. The standard 8 multiplier for the CPU clocked a 2.66 GHz part up to 3.2 GHz, and proved to be more than the system could handle. I dropped the FSB rate to 300 MHz and everything worked fine—until I upped the memory from 4 GB to 8 GB. At that point, I had to turn the FSB rate down to 250 MHz to achieve stable operation. That system has been running non-stop for six days with nary a glitch nor fault.
Achieving Plausible Deniability
I contacted Intel to report my findings and got the following response from George Alfs, who covers desktop processors for Intel PR, “Intel modern processors work on both 32- and 64-bit versions of Windows 7.” Despite my contrary experience with this unsupported and unwarranted engineering sample CPU from Intel, I’d agree with that remark. In fact, of the 30-plus Intel processors I’ve installed Windows 7 on, this one is not only the single solitary item I’ve had any problems with at all, it’s also the only freebie engineering sample I used.
Nevertheless, I found it interesting that despite my exhaustive efforts to pinpoint the cause of my trouble, and the fact that only swapping the processor caused my problem to go away, Intel wasn’t willing to consider let alone concede the possibility that one of their CPUs might be the cause, engineering sample or otherwise. I even offered to return the part so they could confirm this for themselves, but that offer was politely declined—again, because it would involve spending time on an unsupported and unwarranted part. I don’t blame them, but I do find it interesting.
Musings on the Nature and Art of Troubleshooting
One of my favorite quotes from the 19th century master sleuth Sherlock Holmes goes like this: “… when you have excluded the impossible, whatever remains, however improbable, must be the truth” (The Adventure of the Beryl Coronet). In retrospect, looking over the progress I made in identifying, diagnosing, and solving this problem, I can’t help but think that my initial unwillingness to consider the CPU as a possible culprit forced me to solve the mystery through the only method guaranteed to eliminate the impossible and highlight the improbable item that turned out to be at fault—pure brute force and process of elimination.
On the other hand, nothing beats a thorough, comprehensive process of elimination when it comes to identifying causes and taking appropriate action. If I hadn’t tackled the systematic examination of every major possible system component, and swapped each and every one of them out with known, good, working replacements, I wouldn’t have been able to pinpoint and replace the problem part. Too bad my biases steered me to swap out the CPU dead last, or I could have short-circuited the process somewhat. But then, I wouldn’t have had the chance to learn as much as I did, and to be reminded of the value of focus and systematic coverage when it comes to effective troubleshooting techniques.
Want more like this? Sign up for the weekly IT Expert Voice newsletter so you don’t miss a thing!