Upgrading motherboard on Windows 7

Brighamite said:

This worked for me
I recently installed Windows 7 on my computer and had everything up and running. My fried them upgraded his CPU and gave me hi sold one as it was better than mine. This forced me to buy a new motherboard and RAM. After booting with new hardware i got the BSOD. Safe mode did nothing to fix the problem. I figured I would have to do a repair install but found out that you can only run that while windows is running. I decided to try an unorthodox fix and it worked. If you backup your data before trying this then all you have to loose is the time and may have to do a clean install.

1. before changing your hardware, run the setup.exe on the Window 7 DVD while windows is running.

2. Choose an Upgrade install when you get to that option.

3. The upgrade install takes longer since it backs up your files, settings and registry.

4. ***Important Step***** Wait patiently for windows install to reboot your computer the first time during the upgrade install process. As soon as it says it is going to reboot, wait for the screen to go black and pull the plug on your computer.

5. At this point change out your motherboard and turn the computer back on. The HAL file has been overwritten at this point so Windows does not know what hardware was there. The installation will continue as normal but may hang for about 15 20 minutes before going on to the next step.

6. After that it should continue as normal and detect all your new hardware. When mine finally came up I had to load a few drivers and change a few settings but nothing major. So far everything seems to be running stable. :)

Thanks for this!! I had a ton of software and settings just so and when I tried to upgrade the motherboard/cpu of my system I got the Classpnp.sys lockup. I tried all the other solutions first, nothing worked.

Following these steps saved me several days of reinstalling and reregistering stuff, not to mention some on-line purchases I would have had to re-purchase.

Boot old mobo, run win setup, select "upgrade" wait for first reboot, power off before it boots up, swap to new system, keep going. Took about 3 hours, and saved me countless days! (do an image backup first, just in case)

My asus p45 Motherboard died, so i buy an a gigabyte g41 mobo but win7 x64 wont boot.
After of hours of trying everiting, put the drive in a friends p43 mobo, it boots ok, install drivers, restart. Works fine!
Then download the intel chipset driver from gigabyte website, force manual install ICH7 sata driver on the 4 port sata controller,
ask to reboot, turn off.
Put back the drive on the g41, and works!!!

scaramonga said:

Still, I would really rather do a successful upgrade of the OS rather than a clean install.

Your asking for long term problems in the future going down that route. A clean install is always the best option after installing new hardware, especially when replacing the motherboard.
.

When Microsoft split from IBM on the development of OS/2 long, long ago, a major issue was dealing with the OS interaction with hardware - in fact, this was reputed to be the primary factor.

Microsoft's approach was the creation of the HAL - Hardware Abstraction Layer, introduced with Windows NT. The idea was to separate the physical hardware from the OS and applications, that the OS would basically have an interface design where it didn't matter how the underlying actions occurred, you (the application) simply issued an instruction. Kind of like the situation with cars: in a traditional car, you push the gas pedal and a physical link moved a series of connections, increasing the gas flow to the engine. The HAL type approach is what we have with the Toyota Prius (for example), where pressing the gas pedal does not physically move the throttle. Instead, the car's OS reads the pressing of the pedal and then issues appropriate commands to the device which opens the throttle (or fuel injectors, really). Thus, with this example, you could readily replace the "throttle" mechanism with something completely new simply by replacing the driver to which the OS of the car communicates. It need only have the same interface design: increase flow / decrease flow ...

If Microsoft had remained true to this implementation, then swapping hardware around would cause no issues other than simply replacing the driver which the OS uses to communicate with the hardware. The driver would merely have an interface which looks for an object command (open --> door ) and the door would then be opened by the driver which actually implements the hardware. This would cause absolutely no longer term (or short term for that matter) issues with the current installation. You update the drivers for the hardware, and that should be it. I find it rather frustrating and offensive that Microsoft seems to have discarded this approach which was so extremely important, to one that makes life offensively tedious for those who find themselves in need of upgrading/replacing hardware for one reason or another.

While that was a nice trip down memory lane with a thoughtful analogy between mechanical and electronic throttle control, I don't think it's fair to assume that Microsoft abandoned this concept. I think it's more appropriate that they never really perfected it in the first place.

Changing hardware with Windows has always been hit or miss. Sometimes you must trick it into booting. If you're feeling frustrated, just remember that Microsoft has always struggled with not having a hardware standard like Apple. Cheaper prices for the consumers, but more headaches for the developers... and that trickles down to the consumer when you start shuffling things around. =)

All MSFT need do to make this pretty much flawless is to define the interface for the drivers. Then it doesn't matter how the underlying driver is implemented and anyone's hardware/driver will work fine as long as they adhere to the interface. If they don't, then there hardware doesn't work and the mfg will see a whole lot of returned hardware and lose all their customers.

If MSFT were true to the HAL implementaton, then I don't think we'd see these problems. I could be wrong though. I haven't ever worked on designing drivers and don't know where things really stand in this regard.