Swapping Motherboards Under Windows XP
Loyd Case
Recently, I ran across an interesting problem when I was swapping motherboards on a testbed.
Microsoft has stated that an upgrade like a motherboard swap (all other things remaining the same) should not force the user to reactivate Windows XP. As it turns out, that’s not quite true, although the problem seems to be related to glitches in the operating system, not any conspiracy on Microsoft’s part. However, the technical issues surrounding this are enough to make you tear your hair out–and worry about losing valuable data–so I thought I’d share my experience.
The Easiest Upgrade
Recently, we obtained an Intel D850MV motherboard with USB 2.0 down, in the form of the familiar NEC µPD720100 USB 2.0 host controller coupled to the SMSC LPC47M132 low pin count (LPC) bus I/O controller. So I thought I’d upgrade one of the testbeds here so I could give it a spin, which was the beginning of a long journey.
The particular testbed system I chose looked to be a straightforward swap. The unit was running a socket 423 Willamette (Pentium 4) processor–the old style P4 socket. It used an Intel D850GB board that included the Intel 850 chipset. The D850MV that was to be installed in place of the socket 423 board also used the Intel 850, but had the newer socket 478 format. I planned on using a stock Willamette 478 pin CPU in the new board, to minimize any differences in hardware.
To summarize, here’s the table of old versus new:
Component
Old
New
Motherboard
Intel D850GB, Intel 850 chipset
Intel D850MV w/onboard USB 2.0, Intel 850 chipset
CPU
2GHz Pentium 4 (Willamette), 256KB of L2 cache, 423 pin package
2GHz Pentium 4 (Willamette), 256KB of L2 cache, 478 pin package
Memory
512MB PC800 RDRAM
512MB PC800 RDRAM
Boot Drive
Western Digital WD400BB
Western Digital WD400BB
Secondary Drive
IBM Deskstar 75 (45GB)
IBM Deskstar 75 (45GB)
Primary Optical
Toshiba SD-1502 DVD-ROM drive and HP DVD100i DVD+RW drive
Toshiba SD-1502 DVD-ROM drive and HP DVD100i DVD+RW drive
Floppy
3.5″, 1.44MB
3.5″, 1.44MB
Graphics
VisionTek GeForce3
VisionTek GeForce3
Audio
Sound Blaster Audigy Gamer
Sound Blaster Audigy Gamer
Ethernet
3Com 3C905-TX
3Com 3C905-TX
Note that all other components–graphics, hard drives, and optical storage were identical.
Pre-Installation Prep
I had a lot of software installed on the testbed that I wanted to avoid reinstalling. There was also some data I wanted to keep, so I really didn’t want to reformat. (Okay, so I figured I could be lazy, because it looked like an easy swap). I did use Norton Ghost to copy the partition from the boot drive just in case I ran into trouble.
Prior to swapping motherboards, I installed the latest Intel 850 chipset INF update and busmastering IDE driver (aka the “Intel Application Accelerator 2.0”).
I also made sure I had the latest drivers. Now I was set–or so I thought.
So I swapped the new motherboard into the chassis, installed the various expansion cards, attached the hard drive and booted Windows XP. I did expect some re-enumeration of various hardware items, but nothing too onerous.
I was wrong.
At first, everything looked hunky-dory. The system booted, and I was greeted with the Windows XP splash screen. Then, the splash screen disappeared and I was greeted with a dreaded blue screen. The key error message was:
STOP 0x0000007B INACCESSABLE_BOOT_DEVICE
I’d recently started to believe that very little would ever surprise me, after building my own systems for fifteen years now. But this little gem caught me completely off guard. I must have stared at the screen for a good thirty seconds before hitting the reset button. Once again, I was greeted with:
STOP 0x0000007B INACCESSABLE_BOOT_DEVICE
I think I made some whimpering sounds, then rebooted once more. This time, I hit the F8 key and selected safe mode. That should fix it, I thought to myself.
STOP 0x0000007B INACCESSABLE_BOOT_DEVICE
At this point, some seriously colorful language lit up the air in my office. I made a (virtual) visit to the Microsoft knowledge base. It actually took me very little time to find an entry in the knowledge base on this particular error, here:
http://support.microsoft.com/search/preview.aspx?scid=kb;en-us;Q316401
However, let me quote the salient text for you, gentle reader:
“This behavior can occur if the new motherboard contains an embedded IDE controller that has a different chipset than the original motherboard.”
The boldface is mine, not Microsoft’s.
In case you missed that little nugget, let me repeat it for you:
“This behavior can occur if the new motherboard contains an embedded IDE controller that has a different chipset than the original motherboard.”
It has probably occurred to you that the above quote is, on the face, silly. First of all, the person who wrote that statement probably meant to say: “This behavior can occur if the new motherboard contains an embedded IDE controller AND has a different chipset than the original motherboard.” And second, of course, both motherboards have embedded IDE controllers, and both use the same chipset–or do they? Perhaps the south bridge–er, the I/O controller hub–was different. A quick trip to the technical briefs for both motherboards revealed that both did, indeed, use the Intel 82801BA I/O controller hub (ICH2). While it’s certainly possible the chip revisions were different, Intel’s product numbering hasn’t changed.
So the IDE controller was identical between the two motherboards.
On the other hand, the system BIOS was certainly different between the two. I took a look at the BIOS settings for the newer D850MV board, and discovered a binary toggle for booting off USB 2.0. Maybe that was the problem, so I disabled USB 2.0 boot devices. Just to be safe, I also disabled the “high speed USB” BIOS entry. Upon rebooting, I was greeted with:
STOP 0x0000007B INACCESSABLE_BOOT_DEVICE
By now, the problem solving frenzy had completely taken over. Damn all deadlines, I was going to find out what was happening. I swapped in another Intel 850 motherboard, the ABIT TH7-II RAID.
STOP 0x0000007B INACCESSABLE_BOOT_DEVICE
Just for grins, I also popped in an ASUS A7V266-E (VIA KT266-A chipset) with an Athlon XP 1800_.
STOP 0x0000007B INACCESSABLE_BOOT_DEVICE
While I hadn’t yet uncovered the root cause of the problem, I had enough data to go back and peruse the Microsoft knowledge base entry on the stop 7 problem again. Here’s a different passage of relevant text:
“To resolve this behavior, perform an in-place upgrade of Windows XP. This involves reinstalling Windows into the same folder. To do this, follow these steps.”
The MS knowledge base also has an entry describing the details of performing an in-place upgrade here:
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q314112
On this page, there a bit of text that looks quite ominous:
“Use the procedure in this article only as a last resort before you reinstall the operating system. Note that the time required to complete the following procedure is equal to the time that it takes to reinstall the operating system.”
We assume the text “reinstall the operating system” means a complete install from scratch, and not an OS upgrade. Thus if the in-place upgrade fails, the only recourse is to perform a full install of the OS–a cheery thought.
What Microsoft is calling an “in-place upgrade” is essentially a refresh install of the operating system. The steps are essentially similar to a clean install, except you select the “recovery install” option from the Windows setup menu. The catch here is that Microsoft considers an in-place upgrade to essentially be a transfer to a new system. Another link on the knowledge base deals with transferring the OS to a new system: http://support.microsoft.com/search/preview.aspx?scid=kb;en-us;Q314070
There’s a lovely bit of text from the above page that’s important to note:
“The WindowsRepair folder that contains your source computer hardware and software configuration files and the Setup.log file may not be valid for the new hardware on the destination computer to which you restored them. You should perform an in-place upgrade on the destination computer to update these files so that you can make the appropriate repairs in the future if necessary.”
Reading between the lines here, it seems that reactivating Windows might be necessary. That turned out to be true–but it’s worse than even a simple reactivation appears to be.
When I finished the in-place upgrade (which included re-entering the CD key), I was presented with the usual Windows XP initial startup screens. I deliberately skipped the activation phase, just to see what would happen.
What happened was that I wasn’t allowed to log onto Windows. Instead, I was forced to reactivate at that moment in time. This is actually worse than a clean install, which gives you a few weeks to perform the initial activation. Imagine if you’re installing an in-place upgrade on your only system…
The actual reactivation step turned out to be somewhat anticlimactic. I reactivated over the Internet. The activation step wasn’t rejected, nor did I actually have to make a manual phone call. But the simple fact that I had to do this for a very simple swap that involved very few new components is certainly cause for concern.
On top of that, the halt error I received should never have happened in this particular upgrade. This particular error shouldn’t ever happen when swapping system boards with identical IDE controllers. When the Athlon XP motherboard generated this error, it was understandable, though not necessarily forgiveable. Microsoft really needs to clean up the Windows XP boot process. After all, Windows XP is supposed to be more robust than Windows 9x, but I almost never encountered these issue in 9x, and when I did, the fixes were relatively straightforward, and didn’t even require re-entering the CD key.
These days, Microsoft is under the microscope, and every little incident like this only serves to make users trust the company a little bit less. And given the declining perceptions of the Redmond giant among influential technology users, Microsoft really can’t afford to lose even a bit of trust. To me, reactivation seemed like a minor hassle. But when Windows XP actually prevented me from logging on after a simple refresh install, I’m certainly reconsidering my opinion. Microsoft should seriously consider building in an easy refresh install process. After all, wasn’t XP supposed to be both more robust and easier?
Copyright © 2004 Ziff Davis Media Inc. All Rights Reserved. Originally appearing in ExtremeTech.
