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.
| Item | Initial | Tried | Final |
| 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!
slashdot sucks
OK, so why are you still using an antique OS like Windows? Switch to Linux and join us in the 21st century! Bobby B in Houston, Texas
[...] 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. Maybe [...]
"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."
And exactly how many people do you believe will have engineering samples of CPUs? And why, oh why, did you start replacing stuff from the totally wrong end of the line, even so far as to replace cables, before you replaced the CPU?
Please, please, please ! Tell me this a joke… you have problems in the same point during the install every time and memory/cpu/mother board wasn't the first choice? Especially considering you had it working fine in a 32bit OS. Thanks for including your name, now I know what books to avoid.
Actually I had the exact same problem a few months ago upgrading a Dell server from Win2003 x86 to Win2008 x64, I suspected the CPU from the beginning, but I spent a few hours before the Dell Tech agreed with me. They sent a replacement and it worked like a champ.
This proves it has happened to a production Intel Core2Duo CPU at least once, I can't believe I was the only one.
Poster clearly has a lot of experience with software, etc, but limited experience with down and dirty troubleshooting. Let me give you a hint, the first troubleshooting step (after eliminating faulty media of course) is NOT to buy a brand new motherboard.
It's 50/50 on a main board quirk. It would be interesting to see if that cpu will take win7 64bit on a different board. Best try an Intel one if possible. I think Intel are maybe right and I also think that it is more likely to be the main board at fault than the processor.
I'm a little surprised that you didn't try installing 64bit Linux to see if that worked. I guess maybe you have a little too much faith in Microsoft?
If you are installing Win 7 on lots of machines then you should be able to test that processor in one of them and find that out.
Interesting read.
Good article. Above comments are dumb.
Whenever I build a new system, I try to build to middle-of-the-road specifications, and I initially set the BIOS by loading fail-safe defaults. If everything boots up in an acceptable way, then I may venture into tweaking BIOS and/or software settings. Lately though, I have been leaving everything in fail-safe BIOS settings. This general approach to system building works well for me.
Thank you for listening.
A 21st century OS that can't play games or blu-rays. Fail.
I'm not sure why you lay this at Intel's door…sounds to me like the blame could just as well (or even more likely) fall on Microsoft. I'm no Intel fanboy, having used AMD hardware for some years now, but I'm not a Windows user either.
Great article, and a good tutorial on basic troubleshooting (and head-banging) procedures.
I've had 2 clean installs so far. My own machine (Asus m2n32 SLI deluxe) took 7 Ulimate and a couple of days later began a marathon of 10-30 second freezes. On the customer laptop (Asus X71vm) 7 Home Premium simply locked up seconds to minutes after booting up. In both cases removing the ATK0110 driver (a Windows 7 critical update) solved the problem.
Does Windows 7 not like Asus?
Funny that with so many testing and diagnostic apps, one still has to resort to good and old parts swapping.
I used to work as a systems technician (probably not the most correct term, in the end, I fixed not-working computers and assembled / setup new ones) in the biggest computer shop in my town, and in all the years (which have been more than what I wished for) I've worked there, that was THE process to go for, when troubleshooting.
Replying to Nita: In all that time, I've never found a non-working Intel CPU, and I fiddled with everything from P2 Klamaths till i7s. So even tho I've never had a "engineering sample" in my hands, the CPU (if an Intel one), would be my last choice as well.
Your adventure makes me wonder one thing:
When you replace your mobo didn't you move the CPU from the old mobo to the new mobo? Or the new mobo came with a CPU?
And before you tried installing Win 7 on the old mobo, did you ever successfully install / run any OS on that old mobo? What OS was that?
It could be a driver problem, IMHO.
I had the same problem way back when I first tried to install XP. It too caused me to bang my head many many times before I realize something is wrong with the driver that came with the XP installation disk (the Driver.cab file).
So I re-make a new driver.cab with the newest version of drivers that I downloaded from the vendors site, and slipstream that Driver.cab file into the installation disk.
On then the installation work.
What happened to you might not be the CPU. It might be the working in between the CPU and the chipsets, which are controlled by the drivers. So when WIn 7 tries to install the drivers that your chipset doesn't like, the thing hang.
Perhaps your chipset works more in sync with your new CPU and can compensate whatever defect there is in the Driver.cab file.
Microsoft should have allowed the users a chance to include a list of their own choice of drivers in the installation process. Relying solely on Driver.cab file might have caused a lot of unreported head-banger on the userland.
I had a somewhat similar problem. And did pretty much everything you did, but stopped at the ram and CPU.
I had no problem installing, just once it got into windows it would last… oh 5 minutes.
I initially thought it might be the cpu overheating, so I went and bought new thermal paste. Nope
Then a CPU cooler. Nope
Then a motherboard. Nope
Then a PSU. Nope
At that point I was like… you got to be ****ing kidding me.
So i started pulling ram modules. Stable at 1
Stable for a few days with 2
Not stable with 3
Not stable with 4
So I rotated them around under the assumption a single ram module was at fault.
Nope.
Read some overclockers forums to see what they do to get ram stable, up voltages on things.
Okay, lets try that.
Nope.
So I went in the other direction and underclocked the ram (I had 2 sets of 2x1GB DDR 1066 and a Xeon QC 2.4Ghz)
Stabler…
So I wound up clocking them down to 667 and now it runs stable, sometimes for several days.
But I don't feel like replacing the CPU or RAM since those are the most expensive parts "just to see" if that solves it.
Originally I thought it was the video card because back in Vista 64, it would just lock-up shortly after the video glitched. Swapped a Radeon 2600 for a 5750, now instead of a "glitched video" I get a black screen of death (literately, the monitor goes into standby.)
Interesting article…
I'd be interested to know if the "original" configuration + the new proc would work. In that end, that would be the best proof you could offer Inter. "Hey, the proc a didn't work with hardware configuration x or y, but proc b *did*".
CPU was my first thought after mobo =/
I wasted 5 minutes reading this
I think a constipated squirrel could have landed a turd on the defective piece of hardware in less time than you took to find the problem….
Man would some big stores love you as a repair dude, you sure would increase dramatically their revenue.
It would be interesting to try to load a 64bit version of Linux or Solaris on this processor and see if any problems show up. IF they do, there will at least be more detail likely given. I guess it’s just a slightly defective processor.
Dude, I'm sorry, but if you seriously had that much trouble with this and you consider yourself a "tech expert", you're seriously delusional. Go back to school and stop trying to pass judgement on Windows because of your failures. You = FAIL.
Focus? Seriously? Guess that whole "alpha hardware on stock software" wasn't covered when you wrote that last book, eh?
Pathetic. IT expert my @$$. Just another hypester.
I agree with Nita, not only that but have you not through all your reviews and analysis come across some simple Diagnostic Tools for hardware that can be run from a bootable CD or flash drive. My respect for Tom's Hardware just took a dive!
user has engineering sample cpu, fails to check bios after installation, as well as probably before installation, for proper memory settings, probably had memory instability issue all along, apparently did not run memtest86+. would expect trials and tribulations of unnecessary RMAs and misunderstanding of power supply fundamentals from computer support forums, not "itexpertvoice.com", PEBCAK
HI,
um you went into the bios to change settings and had them wrong form the get go and your power supply wasn't rated to cover your parts…. THEN you wasted how many days on this? You've made me chuckle.
[...] This post was mentioned on Twitter by Esther Schindler, derekcslater, derekcslater, Chris Jacobs, Mitr@ Teknologi and others. Mitr@ Teknologi said: pelajaran troubleshooting windows 7 dan masalah hardware http://is.gd/bqjqT [...]
Nice article but good god it was an "engineering sample". Thats the equiv. of "Beta" in the chip world. They are unfinished chips, or those that are not yet properly characterized so you should expect it to fail. Not really a storey here, nothing is at fault other than someone should have warned you that things may be very unstable.
Had a very similar problem with a bad AMD Athlon and Windows XP Home Edition. The installation would hang at 6%. Also, Linux live discs would load flawlessly, but the Ubuntu would not complete a full install either. I first thought it was the drive, but the drive and memory ran fine in another unit. Frustrating, to say the least. Replaced the processor with a like-model and everything started working great.
I'm pretty sure the copy doesn't actually finish with too much RAM and the installer gets ahead of itself without syncing the disk before starting the next step. After reducing the RAM to 8 GB from 4 GB, I managed to copy slow enough that the next step wasn't able to get ahead of the copy finishing.
Glad to see I wasn't the only one experiencing problems on a fresh install.
While reading, I was thinking this was a well-written detective story. Then I got to the end and found out it's a story about a massive waste of time because you didn't follow standard procedures.
Here's how to save a few days next time: go to the motherboard manufacturer's website, get the list of supported CPUs for the motherboard you're trying to install. Then download and install the BIOS that supports that CPU. It really is that simple.
Asus is particularly good at providing a CPU support list for their motherboards. It took me entire minutes to find the lists for the P5Q3 and P5E3 Deluxe (not P5E3 Pro, as you wrote). The QX9650 is listed for both motherboards — and in both cases, it is supported only as of a recent BIOS revision.
So all you had to do was download and install BIOS version 0204 or later for the first motherboard, the P5Q3, and I bet Win 7 would have installed correctly the first time.
As for the motherboard automatically making BIOS changes to match the fast DIMMs you installed, Asus motherboards do NOT do this by default. You must have left the BIOS in some sort of overclocker's mode.
Next time, look up and download the BIOS that supports the CPU you're trying to use. After installing it, use the BIOS setting that restores all other BIOS settings to their defaults. Then install the OS. THEN and only then, can you start tweaking BIOS settings.
Once again, the article was well written. But it's also an inadvertent confession.
Why were you using an engineering sample CPU for your primary test system? Did you know that this piece of hardware may have been faulty in an undocumented manner (or were you led to believe otherwise)?
Were the hours spent troubleshooting the problem worth it? Perhaps simply buying a new machine and salvaging the known working components as spares may have provided a better cost/work ratio.
Seriously, using an engineering sample (Especially if you're using it to test production numbers for a book or professional work, when chances are NOBODY is going to be using an engineering sample in the real world) is just ignorant. Not realizing an engineering sample made years before the OS in question would normally be the first red flag I would see. I'm glad I wouldn't have wasted near as much time, but then again, I work in the real world of IT.
Your troubleshooting order for failed windows installs should be this:
1. Install media (disc or image on thumbdrive)
2. Install device (optical drive +cable or thumbdrive itself)
3. hard drive + cable
4. unplug anything not need to run install
5. ram (multiple modules, any combination of slots)
6a. psu (intel cpu)
6b. cpu (amd)
7a. cpu (intel)
7b. psu (amd cpu)
8. board
UNLESS YOU ARE WORKING WITH NONPRODUCTION ENGINEERING SAMPLES.
Swapping out a modern intel cpu is WAY easier than swapping a motherboard. if you've got multiple machines i bet you've got a 775 around somewhere. I expect that an engineering sample is somehow broken. I can't believe that you went through such an ordeal before suspecting an engineering sample.
Define "Antique" – Linux 0.01 September 1991. WIndows NT – about the same time.
I was waiting for the bit of the story where we find out why that particular CPU kept breaking the installation. Was it actually broken? Would it have installed another OS properly? Why did it work fine until the OS change, and then fail? Without that bit of information, it's just another hardware replacement story, and I have plenty of those all of my own, thanks.
I'm replying to myself.
Having reread the article I'm completely fucking amazed that you failed so hard. This website is called "IT Expert Voice". You have an engineering sample cpu. You sell books on this shit.
I had exactly the same problem described. With a Q9400 installation would crash anywhere between 10 and 90%. The weird thing was the processor worked fine in another board and I could complete the windows install with a Core2Duo E6600 I had lying around. Was just a bizarre combination of board and processor and memory. Probably the most frustrating desktop computer problem Ive ever encountered. After various bios upgrades, swapped HDDS etc, I ended up dropping the voltages on the ram and it worked perfectly ever since. Stupid computers.
Of course, when you have a computer that works fine since years and you install a new software that crashes, the first culprit is hardware.
Thank you Microsoft for the progress of computer science and logic.
In the early times of Linux, you had lists of compatible hardware and there were people fixing issues to make it work on other hardware. When you have to fix hardware to support your crappy software, something is rotten in the state of Denmark !
Similar issue.
Obviously, 64 bits OS have not been fully tested by hardware manufacturers
http://vip.asus.com/forum/view.aspx?board_id=1&am…
It takes you 90 mins to swap out a mobo?
If you switch back to the original CPU, does the system run? I would suppose not, but it'd be nice to know for sure.
In diagnosing this system, after first resetting BIOS and checking the image, given that it failed in the "expanding files" section, I would immedietly look at ram and the hard drive. Next, if the power supply was powering the machine and getting the install that far, but not yet turn on graphics acceleration, I could rule it out along with the graphics card. (You probably still need to change the PSU, and an antec 550W trupower would handle that no problem)
That leaves motherboard and CPU. Motherboards have a fair failure rate, are a pain to warranty, and (as you found out) difficult to source the same motherboard not long after their release. I've also had a bad run with ASUS motherboards, and have seen them far more than gigabyte and intel boards, although they overclock better.
99% of the time, it isn't the CPU. In the last twenty years, I've come across 5 dud cpu's total. I have also come across two computers where the case caused crashes/reboots, and even one phantom machine that we had to replace every component including the case (over time), and it still randomly shut down (we built a completely seperate new system and it worked fine. Never did figure out what was causing it.).
Often when debugging such a problem, you end up with a vastly different configuration than you started with. Look at the table in the article!
To be absolutely sure that the problem is caused by the component you finally replaced, you should go the extra mile and swap the working component with the broken one again, to be sure the problem comes back. Maybe the install is "worst" on the hardware near the 60-something point in the install, and once it's past that, you've got a fighting chance of finishing the install. Which it sometimes does….. So while you now have a single experiment showing that the new CPU works, it could still be that while you were swapping CPUs you touched something else that made things better. Or it could still be a fluke that you managed to install it once on the umptieth try!
Some of the PC problems we encounter are not "single component" problems but "compatibility problems". So while in the end you might be able to swap one component to make the problem go away and come back, still the CPU might just be fine. Maybe with another motherboard, maybe with other RAM.
zzzzzzzzzzzzz
This has been the problem with windows for so long. Things happen in the background, any error messages are hidden, and you have no idea whats really going on.
Ed Tittel, you are a noob and a moron. I do not hope too many of your tests for Toms Hardware went through to the kindernet?
Probably because (a) he already had new cables on hand, and (b) cables are cheaper than a cpu.
Hey Bobby, and Nita,
sorry i had got a witty reponse, but after about six lines of typing got bored. Plus i figured that if you are happy enough to have pasted comments that betray your general lack of intellect on a public forum such as this, then my work here is not required.
anyway, i'm a teapot so your arguement is invalid.
don't forget to feed the trolls.
I cannot believe a pro (…) would waste so much money and time to figure out the issue was the cpu… I mean, someone who is supposedly an expert with hundreds of installs never before encounters a glitch and then when he does, the first thing he does is buy a new m/b? buddy, your *pro* instincts are really baddly tuned.
I had similar problems installing Windows 7 enterprise. It would stop at 0-3% however. After a few days of banging my head against a wall, I decided to try a different DVD drive. Which allowed it to work. It turns out I needed to update the firmware on the DVD drive in the system to allow Windows 7 to install. Never saw that issue with a Windows OS before. FYI, for anyone else with a similar issue, the system I was using was a Dell Optiplex 755. You can get the DVD drive firmware from Dell's site.
Linux has less than 1% of the market share. It would be a better idea to switch to Mac with their 5% market share, lol. Missing software/bad drivers/unfriendly UI's keep most businesses from switching. Once businesses give the go, that's when you'll see things change.
Interesting report, however, i don't believe you've done enough to say conclusively and 100% that the problem lay with the cpu. Yes the system is working, but it no longer is the original system in any real way. To be confident that the cpu was the culprit, I'd want to hear more about how you tried it in multiple other machines that you confirmed to work with an alternate cpu. Also, the ufd, while nice and fast, is problematic every now and then, and I'd be further interested to hear how an original dvd worked for a complete analysis. To me, it sounds like two things here; firstly you were really happy to get a machine working and thought you'd write about it, and secondly you really wanted to be able to find a culprit, and seeing that the cpu was the last thing you swapped before it worked, then it was all its fault.
LMAO… Dude, you're an idiot if you had so much trouble with an install of Windows 7
And this is why i install Mac OS
I had the same problem years ago with XP. Kept getting bluescreens while doing the install, and for me as well, turned out to be the processor. I don't know that I went through as much as you did, I swapped memory, video, hard drive, then processor, and the processor is what fixed it for me too.
I think i had a power surge somewhere along the line with that PC, but only the chip went bad.
I read up to the part where it said, "Banging my head…" and listed the 3 most likely culprits:
1 – Bad targed HDD
2 – Bad source image
3 – Thermal issue – probably processor heatsink
I think I got it with #3. I suspect the OS change made the processor run just a bit hotter, and a heatsink problem (usually too much grease) caused the system to glitch out. He was probably running right at the edge on the 32-bit OS (although my gut says the 64-bit should run cooler). "61 – 62% uncompressed" happens to be the right amount of time after some trigger event and that's why it always craps there.
When something always dies at /approximately/ the same place, the cause is often thermal And thermal problems in PCs are usually (in my experience) too much grease on the processor heatsink. Another clue is the comment about having to clean the Arctic Silver paste off his fingers — that points to too much grease used in the first place.
I'm just happy to hear someone else had this problem!
I've experienced this problem on two of my systems (same base hardware, with exception of CPU being AMD64 4000, and AMD64 4400).
I"ve searched for other's similar experience, without finding anyone else complaining.
I think you're a little over-axious. I've waited up to 48hrs, and in *some* cases, it finishes.
I have gotten lucky, and installed in less than 4hrs on these systems too.
Certainly the oddest thing I've ever run into.
Good to read your article, cause I always thought it was the MB, or SATA DVD drives.
Thanks for sharing!
Dear Bob:
I did the mobo first and the memory second. The point of my story was that I didn't want to suspect the CPU, and thus had to be led to it by process of elimination. Gee, maybe that does make me stupider than you, but perhaps, it's still something that others can learn from (even if it's only to avoid my books in the future).
Thanks for your thoughtful and constructive criticism.
–Ed–
Dear Dan:
Gosh! I've built at least 60 different set-ups for Tom's Hardware, perhaps even as many as 100, over the past 6-7 years. I had been having other trouble with the motherboard, and *wanted* to make a switch. Normally that wouldn't have been my first move, either (memory and drives are the most common culprits in my troubleshooting experience). Once I got into systematic switching, however, I actually enjoyed myself in trying to zero in on the actual cause.
Thanks for your feedback.
–Ed–
Good suggestion about other 64-bit OSes. I'll try that next month when I have some time off, and report back here. As for faith in Windows OSes, I've been working with them too long to exactly consider my attitude toward them one of faith–it's more like "what is it *THIS* time?" Gave me a good chuckle, though. I actually have another sample from the same production batch (it's on my primary production machine right now, though, so I don't want to mess with it). I will be building myself a new i7 PC next month (again, during time off) and will then try installing 64-bit on the other "same processor" just to see what happens.
Thanks for your feedback,
–Ed–
Heh! Heh! I couldn't agree with you more: I was *stunned* to realize that Asus turns overclocking/AI tweaking on in its latest motherboards by default. I generally tend to start up with really basic set-ups: that is, exact clocking of the CPU at rated speed with FSB settings to match, or slower. As soon as I put 4 DIMMs into that mobo, I knew I'd have to turn the FSB clock down because ICH9 memory controllers don't do anywhere near as well with all slots filled as they do with a single bank filled instead (I would normally go with 2 x 4GB to get to 8, but I don't have any spare 4GB DDR3 DIMMs laying around, and they still cost about $200 a pop so I don't want to run out and buy any right now, either).
Thanks for your feedback,
–Ed–
I absolutely don't blame Intel for this: in fact, they are very careful to eschew any and all support and warranty on engineering sample parts. It was my unwillingness to consider the CPU as a possible cause that forced me to solve this problem "the long way around." I'm much more of an Intel fanboy than an MS fanboy in any case, but didn't see how the OS could have caused this particular problem.
Thanks for your feedback.
–Ed–
Dear NTH:
I guess I should count my lucky stars that I use DriverAgent to bring drivers up to snuff, and it steered me to the ATK0110/ACPI driver at the Asus site instead of the MS download. So far, no problems on that front, though I've seen it happen on other builds myself.
Thanks for the feedback.
–Ed–
I agree. Alot of "hindsight" going on in some of those earlier (idiotic) comments.
Gee, your scenario sounds even more "interesting" than mine! My sympathies. I've dealt with flaky memory many times and appreciate your approach. Glad you were able to find a workable compromise.
Thanks for your feedback,
–Ed–
Yes, the original configuration with new proc works, but with old proc does not. I did verify that at some point, but decided that detail wasn't relevant to my story. I'm really not after Intel here, I just want to make the point that "positive paranoia" (it's *GOOD* to suspect EVERYTHING, that is) is a valuable approach when serious troubleshooting is required.
Thanks for your feedback.
–Ed–
If you'd ever debugged a failed install, you'd realise the CPU is rarely the first thing you go for. In fact, in most situations it is rarely the first thing you test. With installation issues, RAM, HDD and install media are the very first things you'd check. The only things I'd have done differently were not trying another USB drive (sometimes, they just aren't quite compatible with a given board) and forgetting that an engineering sample is not the same as a fully supported retail product.
Case in point: I had a hardware job this weekend that turned out to be CPU failure, and I only came to that conclusion by elimination: even my diagnostic tools said the CPU was just fine.
I've got a Sea Sonic Power Angel that measures actual power consumption at the socket. This build never exceeds 280 Watts of power draw. I was pretty sure the PSU wasn't at fault, but in my desire to avoid suspecting the CPU (if you like), or my desire to check everything (which I like), I decided it would be worth swapping out in the interests of thorough coverage.
Where did you get the idea that I had the BIOS settings wrong from the get-go? I left the defaults intact (I assume you're talking about the 2nd mobo, correct) on the faulty assumption that the vendor would go with basic defaults (as has been my experience on every other Asus motherboard I've ever used, for a total of somewhere north of 20 such boards). I may be guilty of overlooking a cursory check, but I didn't change the BIOS in error: I changed it to turn off what proved to be an overly aggressive default.
Glad to bring joy, sunshine, and chuckle into your life nevertheless.
–Ed–
I'm astonished at the amount of prideful people posting here, thinking so highly of themselves and their (supposedly superior) tech troubleshooting methods.
From one tech troubleshooter to another, great article man! Thanks for sharing your trial/insight!
Dear Lucien:
I blame only myself for this. I had been using that chip for over 2 years on 32-bit Vista and Win7 installations without any problems at all. It had been so long since Intel had sent me the chip that I had absolutely forgotten it was an engineering sample until I plucked it out and looked up the on-package info.
Indeed, I am aware that engineering samples are not warranted, not supported, and generally not suitable for production use. I wanted to make the point that all components should be suspect when troubleshooting systems, especially when "truly weird" things start happening–as they did in this particular case.
Thanks for your feedback.
–Ed–
At least be polite to the guy.
I'm running BIOS version 0205 on the P5Q3, and had updated that some time last year. I assure you this was not the cause of the problem. I'll make you the same offer I made Intel: I'll sent you the chip (and if you like) the motherboard as well, and you can try it out to see if you can replicate my problem. I always visit the mobo website to grab the latest drivers and firmware as part of my initial setup routine. I should have documented the BIOS version in my story to forestall your analysis and (as it turns out) incorrect conclusion. Thanks for pointing this out, though: it's a valid point and newbie system builders will benefit from taking this into account in the future.
I am not a newbie.
–Ed–
PS: I'm looking at the box for the replacement motherboard, and I assure both board and box identify the product in question as Asus P5E3 Pro> here's the page on the Asus site for that very product:http://www.asus.com/product.aspx?P_ID=dsHHbxSbteK…
PPS: If you want to take the time to try out the parts, you can find my complete contact information on my website athttp://www.edtittel.com.
The original CPU runs 32-bit Win7 fine, but it won't permit me to install Win7 x64 as documented. That's what I know for sure anyway!
–Ed–
Thank you. Thank you. Thank you. Nice to hear my own longstanding experience vindicated by somebody else. This is the first "partial CPU failure" I've ever experienced. Numerous dead CPUs over the years (occupational hazard when you're assigned to overclock systems) but none that worked mostly, except for this one little thing…
To me, at least, that's what made this story interesting and why I pitched it to Esther in the first place.
Thanks again,
–Ed–
I did try the original configuration with only the CPU different. Same problem. Thanks for asking,
–Ed–
Had that system running for 2-plus years before making the 32 to 64 bit switch. HW Monitor reported temperatures of 27-37 Celsius at the cores, and never over 40 Celsius at the socket. Just re-ran HW Monitor on that machine and temps are as follows (wish I could just stick a screenshot in here):
mobo: 24-27
CPU socket: 25-32
CPU core 1: 35-38
CPU core 2: 33-35
CPU core 3: 38-41
CPU core 4: 38-41 (all preceding temps Celsius)
I *seriously* doubt it was thermal. I always watch my temps and that build ran cool for so long in advance of the switchover that I'd be surprised if temps caused my problem. Besides, why would the same cooler/CPU work (and install) Win7 x86 flawlessly but bork on x64. Surely, both would overheat at more or less the same time?
Interesting hypothesis, though.
–Ed–
[...] noticed a nice little story of a professional technology author having problems installing Windows. He replaced [...]
How is there anything to learn here? Is the lesson "Replace everything without regard for how likely it is to be causing the problem?" or "All other information except that something isn't working should be ignored (hint: your CPU is the thing most likely to care about the OS's 64 bit change). or "Assume there are no changes between ES and production equipment?" *shakes head*
Dear Penang:
1. I did move the QX9650 from the old P5EQ3 to the new P5E3 Pro.
2. The original build ran Vista Ultimate for 1.5 years and Win7 Ultimate for nearly a year (both x86/32-bit) without any apparent problems
3. It pretty much has to be the CPU, because I can make things work by holding all other parts constant and using a different LGA 775 CPU, then make them fail by holding all other parts constant and using this particular CPU.
I agree with your point about MS including a facility to slipstream drivers into an install more easily. This can be done using various tools like Sysprep, but it's time consuming and not terribly fun.
Thanks for your feedback.
–Ed–
Hey! I used that system for 2-plus years on 32-bit OSes without any problems at all. I started working in IT in 1981/2, possibly before you were born. If the system hadn't worked fine for so long I wouldnt' have been so cavalier about switching from 32- to 64-bit. As I said in a reply to an earlier posting, it had been so long since Intel sent it to me that I'd actually forgotten it was an engineering sample until I popped it out and check the package information. I just thought it was an interesting troubleshooting exercise and wrote it up as such. It's your privilege (and apparent pleasure) to think otherwise.
Thanks for the feedback,
–Ed–
Gee that's pretty much the order I followed myself, except for putting the mobo and PSU ahead of the CPU. As I have now stated in replies to numerous other posts, I'd actually forgotten the chip was an engineering sample, because it had been working without any problems for over two years (in 32-bit mode, however). I thought it was an interesting exercise in troubleshooting nevertheless, and wrote it up as such.
Thanks for adding some cogent and relevant advice to the overall content of the story.
–Ed–
I don't know why the part dislays its particular and unique (in my experience, and in my research of available information, forum postings, and so forth). I had hoped to get Intel to dig in and see what was up but they were emphatically not interested. If you have some ideas on how I might go about testing further, I'm certainly game to try.
Thanks for the feedback.
–Ed–
You're welcome! Comments about my sanity, troubleshooting skills, and general competence notwithstanding, I really enjoyed–and continue to enjoy–this entire adventure!
–Ed–
This is interesting. I have an Asus P5W DH, and a Q9650 which refuse to even start the install.. It crashes with bluescreen midway through bootup when trying to install Windows7 x64.. Windows XP x64 on the other hand is no problem. Works like a charm.
It's always worth checking out RAM specifications from manufacturer page.
By default, motherboards supply 1.8V if you are using DDR2.
My system was also pretty unstable. Then i found out, that my DDR2 800MHz OCZ RAM chips are actually designed for 2.1V in normal operation!
After upping the voltage from BIOS it's completely stable.
Out of curiousity, was it not possible to use memtest86 on this system?
I've been doing this for years, not as extensively as you have, of course. But your approach seemed to be outside-in. Now, in my old age, I always do it inside-out, starting with memtest86. That is, after I first reseat the drive cables and maybe the memory chips.
– Roy Zider
Everyone… And I mean everyone… Even the fails above that have no respect… has had a system that just humbled us. Those 3 AM moments, after drinking two gallons of coffee, still in the clothes you had on the previous morning, and looking twitchily at a server that has started to make your ears bleed from frustration… If you haven't had one of those moments, you don't know what the hell your talking about when it comes down to it. So keep the good faith, man. You figured it out, and you fixed it. End of story.
Note that the final configuration is not the starting configuration with only the cpu changed out, so the conclusion remains speculative. Yes, scientific method is picky like that. Interesting to see how the first thing this experienced windows installer guy does when the shit hits the fan is buy new hardware. Me, I've been carting around the same install over several different machines, with very little trouble. Currently running the latest and greatest version on recent and ten year old hardware both. But then I don't use microsoft products at all.
[...] Nos gusta imaginar que cada instalación del sistema operativo funcionará igual de bien que el vendedor promete. Cuando las cosas no salen bien, la identificación y reparación si ésta no puede ser lento y frustrante. Esta lección de "cómo saber por qué Windows 7 no ha instalado el paquete" puede ayudarle a solucionar un problema de su [propia. . . ] URL del artículo original http://itexpertvoice.com/home/lessons-in-troubleshooting-focus-and-systematic-coverage-are-key/ [...]
[...] Nous nous plaisons à imaginer que chaque installation de l'OS fonctionnera aussi bien que le vendeur promet. Quand les choses ne fonctionnent pas, d'identification et de la réparation le cas de l'échec peut être long et frustrant. Cette leçon de «la façon de déterminer pourquoi Windows 7 n'a pas installé" peut vous aider à résoudre un problème de votre propre [. . . ] URL article original: http://itexpertvoice.com/home/lessons-in-troubleshooting-focus-and-systematic-coverage-are-key/ [...]
Gee that's pretty much the order I followed myself, except for putting the mobo and PSU ahead of the CPU. As I have now stated in replies to numerous other posts, I'd actually forgotten the chip was an engineering sample, because it had been working without any problems for over two years (in 32-bit mode, however). I thought it was an interesting exercise in troubleshooting nevertheless, and wrote it up as such.
Thanks for adding some cogent and relevant advice to the overall content of the story.
–Ed–