Windows Vista working after Hardware change

[klau1]

I discovered how much Vista has improved over XP under the hood. Now, granted I've never been impressed with the efficiency of Vista, the fact that Vista proved it can survive an intensive hardware change is commendable.

My old set up was:
Intel E8400
MOBO: P5N32-e (nVidia 680i) chipset
Video: 8800GTX
HD: no change

New set up:
Intel i5-750
MOBO: Gigabyte P55 UD3R (Intel P55) Chipset
Video: 280 GTX
HD: no change

Here we have a change in not only the chipset version, but also brand. I fully expected it to blue screen like it would certainly have in Windows XP.

Interesting.

 

[SimMike2]

Did you have to reactivate your copy of Vista?

What usually is the real killer is when you change to a completely different motherboard chipset, Nvidia to Intel in your case. While some people frown on what you did, saying it will make your system buggy, I don't think so. Software is what really makes your computer buggy, that and viruses. Slowly over time, it gets more corrupted. Where with hardware changes, it is relatively easy for Windows to swap in new drivers and away you go.

 

[Red Squirrel]

I've seen major hardware changes like this totally crap out at times, and other times work very well. With XP, and even Linux. It's odd really. I remember trying to move an old NT server to a VM. Now that was fun. Go from a dual 486DX to a quad xeon + virtualization. Surprisingly it worked but it was kinda unstable. It's sad, but I actually see quite a lot of NT servers still in production. Usually running legacy custom apps that wont work in 32bit (let alone 64).

 

[ViRGE]

Vista and later are much better about hardware changes than XP was. It's not perfect (and you're probably still better doing a reinstall), but for most people it seems to work.

 

[Nothinman]

Welcome to the 20th century. =)

I ported my last Linux installation across 4 or 5 machines, including at least 1 notebook. I did eventually reinstall like 3 or 4 years ago so that I could get a pure 64-bit installation but that was the only reason.

I've seen major hardware changes like this totally crap out at times, and other times work very well. With XP, and even Linux.

That's you. You seem to be the exception more than the rule. These days Linux generally just works and even if it doesn't it takes like 10min to boot up a LiveCD and fix it.

It's sad, but I actually see quite a lot of NT servers still in production. Usually running legacy custom apps that wont work in 32bit (let alone 64).

NT 4 was 32-bit so that sentence makes no sense. However, anyone still running NT4 should be fired or shot.

 

[ElFenix]

i never had a problem with major hardware changes in XP. i even tested it with an old install (that had been through several changes) up against a brand new install and the old install actually benchmarked slightly faster

one of my xp installs started out on a single core athlon64 with an x800 video card, moved to a dual core c2d based pentium on a via chipset with an x1300, switched to an nvidia 7300le, then to a q8200 on a g31, and is now on a q8400 on a p43 chipet. no issues other than having to reinstall USB drivers every time (i still can't figure out why my bios supports USB keyboards immediately but windows needs a restart or two). if i can figure out how to get it to run under a VM in windows 7 that'll be another change.

 

[notposting]

Yeah it can be surprising, though I did have some success especially with my wife's machine under XP. Using Acronis and a trio of HD's, I went from an Athlon XP w/Via chipset, to Athlon 64, to Athlon 64 X2 (both of those with Via also however).

And Vista was pretty sturdy as well in our HTPC--went from a S754 based system (Via chipset) to a new AM2 board, dual core (Via again though ), new graphics card and dvd drive. Did it's driver shuffle, I had some DRM issues to sort out, and then reactivated online.

I definitely prefer Vista/Win7 (and Server 08 I guess) ability to handle changes though. And better with SATA and newer hardware for sure. I did have to reinstall WHS changing from S754 (Via) to an AM2 board with an AMD chipset. And I've never had to call in to reactivate for any of them.

Of course, all 4 of our machines run Win7 now...though I think I preferred VMC to the new one in our HTPC.

 

[JackMDS]

When installing Win XP the installation copies from the CD what it needs for the specific installation and leaves the rest on the OS’ CD.

Vista, and Win & copy most of the content of the DVD to the HD. Thus, the OS’ Database is available on the HD.

As a result, when trouble occurs Vista and Win 7 are more capable to self-correct and recuperate.

When changing the core hardware, most of the time the BSOD occurs after the initial Boot when Windows has to change from the generic Boot drivers to the specific IDE/SATA/HD drivers.

If the drivers from the previous hardware are incompatible, it cannot read the HD, cannot self correct and thus Crash.

When the move is from (example) Intel platform to AMD (or vice versa) it usually crash at that point.

When the move is within the same Platform many time in Vista and Win 7 the drivers can somehow fit and self-correct.

In case of the OP, he moved from Intel to Intel.

There are few ways to deal with the issue.

The complicated one is using Windows tools like sysprep if you want to create an image in a work environment with many computers that are loaded the same way.

Otherwise, it is easier to get Acronis TrueImage 2010 and buy the Universal Restore Ad-In.
Before the upgrade make an Image of the hard drive and store it on the Network or on an external hard drive.

Build the new system and use TrueImage CD to boot. At a certain point during the process, Trueimage would ask if you want to do Universal Install. Check yes.

It would load back the content of the drive and during the ghosting would strip all the specific previous drivers and install generic drivers (or drivers that you can provide through the external drive).

In most cases you would have a New Bootable system with all the previous installation.
All you have to do is provide the drivers to the peripherals in the Device Management that have the need for new drivers.