I have just gone through **** in relation to my legal OEM copy of Windows XP. Here’s the situation:
1. I performed a clean installation of Windows XP (SP1) onto an IDE-drive; after jumping through countless hoops, I managed to get it updated to SP3, with all auto-updates (more than 150!) completed successfully. This is my baseline-installation, whose purpose is to serve as the source for cloning to my SATA-drive, and to enable me to start with a clean slate in an emergency.
2. I cloned the IDE-source to my SATA-partition using Linux-based cloning software. I then removed the IDE-drive from my system, and then booted it. I found that I was able to access the SATA-copy with no problems; once I booted it, CHKDSK fired-up automatically to check “drive C:” for “inconsistencies” that were introduced as a result of the cloning-process (i.e., mismatched cylinder-boundaries). They were repaired successfully (as per normal behaviour observed following previous clones to the same drive), and then I was prompted to reboot. Upon logging-in, the SATA-drive was detected, and the required SATA-driver was installed. I could then use this partition problem-free following another reboot.
3. After a few weeks of use (which included a few auto-updates), I decided that I had better update the original as well, before its support-period ends in April, 2014, so that any further bugs and security-holes would be fixed. I noticed no problem with the original following the updates; I was able to successfully log-into all accounts on this drive. However, I made the mistake of leaving the SATA-drive connected as I booted the original to check it; Windows saw my SATA-copy, and labelled it F. This is where my problem began.
4. To take care of an instability-issue on the SATA-partition that occurred with my TV-tuner app, I then recloned the updated original to my SATA-drive. After disconnecting the IDE-drive, and rebooting, I noticed that it was now Drive F that was being checked by CHKDSK, not C as in Step 2 above. Furthermore, I could no longer access the login-screen; Windows would go no further than the blue splash-screen.
6. After 2 days of intense frustration, I discovered what I needed to do to regain access: I removed the /NoExecute=OptIn command from the original’s BOOT.INI file, uninstalled its SATA-driver, and then recloned it to the SATA-partition. Once again, it was Drive C: being checked by CHKDSK. Problem solved.
What on earth was going-on here?
