CPU change from Intel to AMD produces stop code 7B on bootup

[Confuzzled]

Summary: XP Pro System crashes with stop code 0X000007B (0XF7977528, 0XC0000034, 0X00000000, 0X00000000) after being booted from a different CPU family. Old CPU=Intel, new CPU=AMD. Hardware abstraction layer issues?

Background:
Existing system is an Intel CPU 2.6Ghz on a Gigabyte GA-8SIMLH-P motherboard. It is working well and has all the latest software patches and driver updates applied.

It is used in a small office environment, mainly as a type of server, having lots of customisation to the security attributes for different shared folders across a LAN, FTP server, custom IP addressing, user attributes on secured folders, etc. Rebuilding the software from scratch is not a viable proposition - it would take too long and I'm sure I would miss something. System is fully backed up daily and has not been having any problems of note, but is starting to buckle under the load.

Along comes a AMD CPU running at 3.4Ghz on a Gigabyte GA-K8N Ultra-SLI motherboard with added oomph in the way of extra RAM and a faster graphics card. Clone the drive and put it in the new motherboard system and fire it up. During startup up comes the blue screen of death with the stop code as shown above.

Popping in a new drive on either system and doing a fresh full install works fine with no problems - the hardware is 100% functional on both motherboards - no questions of unreliability as diagnostics have passed with no errors on the drive, CPU and all other components.

Issue:
I want to change the XP drivers to recognise the new CPU and at least boot up so that I can do a refresh update, add the appropriate device drivers, or patch the appropriate driver files and registry entries directly.

I've tried http://www.sageadvice.com.au/winxp-moving_to_a_new_motherboard.htm, attempted a refresh and repair install, and nothing gives me the results needed. I've gotta preserve the current software configuration for security and network attributes, and because many people have worked on this system and a lot of the customisation is undocumented, the Microsoft recommended solution of a new install cannot be contemplated.

I've got flexible access to boot from either motherboard and a third machine to copy files and registry entries.

I know its a problem with the Hardware Abstraction Layer for either the CPU or IDE controllers as Windows boots part way before showing the blue stop screen, both in safe and normal modes.

Any clues or ideas on how to identify the appropriate drivers and registry entries to change to make the old system disk work with the new motherboard? Surely somebody has tackled this issue before?

Any help or pointers would be most appreciated. I will provide feedback on success/failure of your suggestions.

 

[site3op]

I've never done this myself, but the following registry locations are of interest: hkey_local_machinehardware and hkey_local_machinesystemcurrentcontrolset.

My thoughts are to get a spare drive and do a fresh install on the AMD system. Save off these areas of the registry to floppy or CD. Then import them on the ghosted drive while it's in the old system (obviously having the original drive safely removed.) Once the values are imported, remove power to the computer (in lieu of normal shutdown which will write to registry) and transfer the drive over to the new system.

Once again, I haven't done this, but it may do the trick in at least getting the system to a bootable state to start driver repair.

I take it you've attempted the safe-mode boot?

 

[Confuzzled]

Safe mode produces the same stop code.

I didn't think to power off before shutdown, and will try the parallel install and import method. Thanks for your ideas. I'll let you know how it goes.

 

[Confuzzled]

No good news yet! Exporting the two relevant registry trees worked. Attempting to import them again fails. Even attempting to delete them (understandably) fails also.

Would keeping the same registry entries and just swapping the relevant driver files do the job? Anybody know which ones they are?

 

[pscowboy]

NOT possible! Thousands have tried.

The hardware hash "married" to your Key from the Intel cpu unit is comprised of video, ide controller, ram, cpu type, cpu serial #, cd-Drive, hd volume serial# - all one vote. The nic has 3 votes. Last, but not least (without a vote) are the chipset drivers.

Assuming also a new network interface on the new Giga mobo, you have changed EVERYTHING except the hd type - only one vote. You must have seven votes the same to pass bootup. Welcome to the lovely world of XP.

You could manipulate drastic hardware changes in 98 by deleting an enum key. This won't work under XP.

What do you mean by "buckling"? Perhaps that issue can be addressed?

 

[Confuzzled]

I wasn't trying to keep the same Windows registration, just get the system running on the new motherboard. From experience, calling Microsoft and explaining that you have replaced the motherboard with a newer model will allow you to re-use the same serial number on the new one without any problems - just make sure you don't fire up the old one again and connect to the Internet!

Belated update:
I took the advice of all and tried many things.

Finally the only thing that worked was to uninstall all hardware devices from the Control Panel / System / Hardware Devices, and replace the drivers with the generic Microsoft ones while still booted from the old motherboard in safe mode and then the hard drive would boot from the new motherboard.

Not taking any chances, I immediately did a 'refresh' install over the top of the existing one and made sure that any drivers for hardware that were not present on the new motherboard were deleted from the C: WINDOWS INF folder and associated drivers in C: WINDOWS SYSTEM and SYSTEM32 folders.

Did some analysis of logs later on the cloned drive and found that the problem drivers were the VIA chipset on the old motherboard were being called during bootup to initalise the nVidia chipset on the new motherboard with disastrous consequences. If the chipsets were the same, it probably would have worked. Ah, the benefit of hindsight!

After experiencing some issues with stability after a few months after a suite of "patch Tuesday" Microsoft updates were installed, the decision was made to re-install everything on a fresh SATA II drive and set up the permissions and other customisation from scratch and just copy the required data across.

This has resulted in a substantial performance boost to the system and rock solid stability. As a byproduct, all install steps and customisations are now well documented for the future.

Thanks to those that offered hints and suggestions.