/NoExecute=OptIn renders SATA-clones inaccessible in win xp

By techturbo-geek416 ·
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?

This conversation is currently closed to new comments.

Thread display: Collapse - | Expand +

All Answers

Collapse -


by techturbo-geek416 In reply to /NoExecute=OptIn renders ...

I made a mistake in the second-last paragraph above; it should be 5., not 6.

Collapse -

It's Windows

by HAL 9000 Moderator In reply to /NoExecute=OptIn renders ...

It knows what is required better than you and makes sure it gets it's own way.

Your mistake was to leave the cloned SATA drive Connected while the IDE drive was fitted both with valid Operating Systems and no Dual Boot setup. Obviously this can not be correct so Windows Fixed the problem.

Of course the IDE drive is always the hardware Default Boot Drive and any SATA drive is an accessory drive.


Collapse -

Re: It's Windows

by techturbo-geek416 In reply to It's Windows

Thank you, HAL 9000 for your prompt reply. 2001: A Space Odyssey (i.e., where you are from) happens to be my favourite sci-fi movie of all time; Stanley Kubrick was clearly WAY AHEAD of his time with that one! :)

After researching the function of the /NoExecute=OptIn command, I decided that I had better put it back into my SATA-copy for additional protection; remarkably, when I did this and rebooted, I then had no problems accessing my accounts on this partition. However, I remember (prior to my discovery of this command within the BOOT.INI file of the IDE source-disk) doing the following in a previous attempt to solve my problem:

1. reconnecting the source, leaving the SATA-drive also connected,
2. rebooting the source,
3. uninstalling the SATA-drive from the source,
4. recloning the source to the SATA-drive,
5. disconnecting the source,
6. booting the SATA-copy.

Following Step 6 above, I experienced the same weird behaviour; when CHKDSK fired-up, it was still "drive F:" that was being checked, not "drive C:", and the account log-in screen did not display. It was only when I removed this command, and repeated Steps 1 to 6 above that I noticed things returning to normal (i.e., "drive C:" checked by CHKDSK, and my being once again able to log-in to my SATA-accounts). Evidently, this command was preventing Windows from reinitializing the SATA-partition properly; it remembered that it was labelled Drive F: previously within a non multi-boot environment, and refused to reinitialize itself as Drive C:. Since it was still labelled as such, it would then refuse to display the log-in screen.

At first, I was led to believe that something sinister was at work (perhaps M$ employed this trick so that Win XP users would eventually be forced to upgrade to the latest version of Windows once they discovered that they could no longer rescue their XP installations from their IDE source-disks); that would have left me out-in-the-cold, since no Win 7 or 8 drivers exist for my particular Intel Pentium-IV motherboard, meaning that I could not reliably upgrade even if I wanted to (Ironically, this computer is now better-supported in modern versions of Linux than it is in more-current versions Windows--even though it has a sticker that says, "Designed for Microsoft Windows XP"!). It was only when I researched this command further that I discovered that this was indeed not the case, since it gave me no trouble with my initial clone to the SATA-partition.

Related Discussions

Related Forums