Re-installing Windows XP isn't a good idea as a blind first step in troubleshooting problems, but there are specific contexts where it is necessary, as the cleanest way to "make things work". One of these contexts is after a motherboard change that invalidates XP's core assumptions, typically causing a STOP BSoD on any sort of attempted XP boot (from Safe Cmd to normal GUI).
This is the situation that edgecrusher is in, as posted in comments to the previous post in this blog, and this post is my response.
Before you start
Firstly, I'm going to assume you have all the necessary installation and drivers disks, have your XP product key or retrieved this via Nirsoft Produkey or similar, excluded malware, and verified RAM overnight e.g. via MemTest86 or MemTest86+ and hard drive e.g. via HD Tune.
Make sure the edition (OEM vs. retail, Home vs. Pro, etc.) of the XP installation disk you will use for the repair install is one that matches your product key, that the disk actually has the ability to do a non-destructive install (as many OEM disks do not), and that the disk can be read without errors (as tested by copying all files to a subdir on the hard drive before you start).
It's a good idea to make a partition image backup of your XP installation before you start, using something like BING. Simply copying off every file is not enough, because unlike Windows 9x, XP will not work when copied in this way.
Also before you start, you may want to uninstall any OS-bundled subsystems that you've upgraded past the baseline of your XP installation disk, such as IE7 or recent versions of Windows Media Player. Things are cleaner and more likely to be "supported" if you uninstall these before the repair, and re-install them afterwards, plus you'll have valid entries in Add/Remove Programs should you need to uninstall them again later (e.g. as a troubleshooting step).
Several sites describe the XP repair install process, starting from how to start the process, and going on to a step-by-step slide show or providing more detail. In this post, I will mention a few specific gotchas to avoid...
137G capacity limit
If your hard drive is over 137G in size, then the Service Pack level of the Windows XP installation disk must be at least SP1 to install, and SP2 to live with. In other words, you cannot safely install XP "Gold" (SP0) on a hard drive over 137G, and should apply SP2 or SP3 over an XP SP1 installation.
If your install disk pre-dates SP1, you need to slipstream a later Service Pack into this and make a new installation disk that includes SP1 or later, built in. Your other option is to install XP "Gold" onto a hard drive smaller than 137G, apply SP1 or later, and then use a partition transfer utility to copy the partition to the larger hard drive where the partition can then be resized to taste.
XP "Gold" has no awareness of hard drives over 137G and is very likely to mess them up. XP SP1 is supposed to be safe on such hard drives, but there are some contexts where the code that writes to disk is unsafe and may cause corruption and data loss; from memory, these contexts typically apply to C:, e.g. writing crash dumps to the page file. XP SP2 and SP3 are truly safe over 137G.
F6 driver diskette
Yep, you read right; that's "diskette" as in "ancient crusty old stiffy drive"!
Most current motherboards have S-ATA hard drive interfaces that are not "seen" by the native XP code set (affecting Bart and Recovery Console boot disks as well).
The trouble is, the latest PCs often have no diskette drive, and the latest motherboards often have no legacy diskette controller. You may come right with an external diskette drive plugged in via USB. You'll also have to find and download the relevant driver diskette image and make a diskette from this, if yours is missing or unreliable.
If you use a USB keyboard, and this is not initiated at the BIOS level, then your F6 keystroke to read the driver diskette will be missed. If so, you can plug in a PS/2 keyboard... as long as your new motherboard has PS/2 sockets; the newest ones don't.
Sometimes your mileage may vary, depending on the mode that your S-ATA is set to operate in CMOS Setup. RAID and AHCI will generally not be "seen" natively by XP's code, whereas IDE mode may be. But some nice S-ATA features may not work in IDE mode, e.g. hot-swapping external S-ATA or NLQ, and changing this after XP is installed may precipitate the same crisis as the motherboard swap... requiring a repair install to fix, again.
All of this is a reason why I consider the XP era to be over, when it comes to new PCs. I appreciate how old OSs run beautifully fast on new hardware, and how attractive that is for gamers in particular - but XP's getting painful to install and maintain, and this is going to get worse.
Duplicate user accounts
Later in the GUI part of the installation process, you will be prompted to create new user accounts. You can try to skip this step (best, if that works... I can't remember if it does), or create a new account with a different name that you'd generally delete later.
But many users are likely to create a new account with the same one as their existing account, and that's likely to hurt...
The two accounts will show the same name at the Welcome screen, but both will be selectable via this UI; I have no idea what will happen if you were to force the more secure legacy logon UI, which requires the account name to be typed in.
Each account will have a unique Security Identifier (SID), which is the real "name" used behind the scenes - but you can't login with that. There will also be separate account subtrees in "Documents and Settings"; the one with the plainest name is likely to be the original, and the one with numbers or the PC name added to it is likely to be for the newly-spawned account.
At this point I'll mention another user account hassle that I generally don't see, because I avoid NTFS where I can. If you find you can "see" your old user account's data, but aren't permitted to access the files, then you may have to "take ownership" of these files from a user account that has full administrative rights.
This issue is well documented elsewhere; search and ye will find!
Broken update services
It's a given that the "repair" is going to blow away all patches subsequent to the baseline SP level of the XP installation disk you are using, unless you've slipstreamed these into your installation disk.
What's less obvious is that after you do the "repair" install, you won't be able to install updates. It doesn't matter whether you try via Automatic Update, Windows Update or Microsoft Update, the results will be the same; the stuff downloads OK (costing you bandwidth) but will not install, whether you are prompted to restart or not.
The cause is a mismatch between the "old" update code within the installation CD, and the newer update code that was controversially pushed via update itself. I can see Microsoft's logic here; if you ever wanted updates to work (e.g. you'd chosen "download but don't install", or disabled updates while planning to enable them later), then the update mechanism has to be updated - but doing so, invalidates the original installation disk's update code.
This topic is well-covered, as is the fix; manually re-registering a number of .DLLs that are needed for the update process to work.
Broken settings
It's often asserted that a repair install "won't lose your settings", and is yet waved around as a generic fix for undiagnosed problems. Part of why it sometimes works as a "generic fix" is precisely because it can and does flatten some settings, which may have been deranged to the point that the OS couldn't boot!
So if you do apply any non-default settings, you should check these to see if they've survived. I always check the following, and can't remember with certainty which ones survive and which don't:
- System Restore (may be re-enabled on all volumes)
- System Restore per-volume capacity limits
- Automatically restart on system errors
- RPC Restart the computer on failures (may survive)
- Show all files, extensions, full paths, etc. (may survive)
- NoDriveTypeAutoRun and NoDriveAutoRun
- Standard services you may have disabled
- Hidden admin shares, if you'd disabled them
- Recovery Console enabling settings
- AutoChk parameters in BootExecute setting
- Shell folder paths
- Windows Scripting Host, if you'd disabled it
- Settings detail in IE, including grotesquely huge web cache
- Windows Firewall settings; may be disabled if < SP2 !!
- Anything else you've dared to change from duhfaults
It's particularly crucial to enable the Windows Firewall (or install a 3rd-party alternative) before letting your PC anywhere near any sort of networking, especially the Internet, if your installation is "Gold" or SP1. Not only do these dozeballs duhfault to "no firewall", they're also unpatched against RPC (Lovesan et al) and LSASS (Sasser et al) attacks, so you'd be "open and revolving".
By now, the original PoC Lovesan and Sasser worms may be extinct, but these exploits are often crafted into subsequent workaday bots and worms. You may still get hit within an hour of plugging in the network cable if so, and probably before you can pull down updates for the OS, antivirus scanners, etc.
