Why should XP require TWO different boot partitions to boot from SCSI?

XP boots fine from SCSI disk, but *ONLY* if there's another XP boot partition elsewhere!

Brief Description:
XP will boot perfectly from my SCSI disk *ONLY* if there's another XP boot partition on some other drive!  If the SCSI boot partition is the only one in the system, it will not boot correctly.

Detailed Description:
I apologize in advance for the length of this, but you never know what piece of information might help, so here it all is!

I used Acronis Disk Director 10 to clone my working XP boot partition from one of my SATA disks to my SCSI disk.  And it boots perfectly -- *UNLESS* there is no other XP installation on a different disk.

Here's the situation.  If I have a second XP installation on another drive, XP boots perfectly from the SCSI disk.  However, in that situation, the boot process awards the other (non-SCSI) XP partition the letter C, which is completely unacceptable in my situation.  So, if I hide the other (non-SCSI) XP partition, the boot process thankfully awards the SCSI boot partition the magic letter C.  However, in this case XP won't fully boot from the SCSI drive, even though it's the C drive.

Why on earth should XP require TWO boot partitions in order to boot from a SCSI drive with drive letter C?

This is what happens if I try to boot from the SCSI disk without the other XP partition visible:

1) I boot & select the SCSI boot partition in the XP boot loader window (the default)

2) Up comes the Windows XP welcome graphic with the blue Cylon eye on the black background

3) Then comes the Windows XP graphic that is sky blue with darker blue upper and lower borders.  However, in a fully working system, you next see the phrases "Windows is starting up" followed by "Windows is loading your settings", etc.  But these never show up.  What happens instead is that the entire window turns sky blue (NOT the Blue Screen of Death color), and although the mouse responds, the system is completely hung and non-responsive.  Ctrl-Alt-Del does nothing.  I'm forced to do a hard reset.

If I boot into "safe mode" or "safe mode with command prompt" instead, everything also looks perfect at first.  The exact same text messages saying loading this and loading that are there.  It gets to the Safe Mode graphic ("Safe Mode" in the corners).  But then the system gets into an infinite loop, repeatedly showing a sky blue sub-window graphic for about 1-2 seconds, then it blanks, then it repeats ad infinitum.  Again, Ctrl-Alt-Del does nothing.

The KEY here for me is the boot time assignment of drive letter C.  If I could get XP to assign C to my SCSI boot partition no matter what, then I wouldn't care if there had to be another copy of XP on the system.  But no matter what I try, if there's another XP boot partition anywhere in the system other than the SCSI drive, it always gets to be drive C.

Thus in order to force my SCSI partition to be assigned C, I have to "hide" the other XP boot partition, whereupon XP will call the SCSI partition "C".  But then it won't boot correctly!

Does anyone know any other way to force XP to assign C to a particular disk/partition?  Is there some OS loader or something that does that? I'm not afraid of editing the registry or even the boot sectors of the disk, if that's what it takes.  Or does anyone have a link to exactly how the XP boot process determines which partition is awarded the "C" drive letter?  (It's changed since Windows 98, and perhaps other later OSs too).

To try to get at the bottom of this, I compared the boot logs between a good SCSI boot (with another XP elsewhere) against the failed SCSI boot (with no other XP visible). The following differences showed up: (note: these are all in the good boot log and missing in the failed one, even the "Did not load driver" messages):

Loaded driver \SystemRoot\System32\DRIVERS\USBSTOR.SYS
Did not load driver \SystemRoot\System32\Drivers\Fastfat.SYS
Did not load driver \SystemRoot\System32\DRIVERS\rdbss.sys
Did not load driver \SystemRoot\System32\DRIVERS\mrxsmb.sys
Loaded driver \SystemRoot\system32\drivers\wdmaud.sys
Loaded driver \SystemRoot\system32\drivers\sysaudio.sys
Loaded driver \SystemRoot\system32\drivers\splitter.sys
Loaded driver \SystemRoot\system32\drivers\aec.sys
Loaded driver \SystemRoot\system32\drivers\swmidi.sys
Loaded driver \SystemRoot\system32\drivers\DMusic.sys
Loaded driver \SystemRoot\system32\drivers\kmixer.sys
Loaded driver \SystemRoot\system32\drivers\drmkaud.sys
Loaded driver \SystemRoot\System32\DRIVERS\mrxdav.sys
Did not load driver \SystemRoot\System32\DRIVERS\parport.sys
Loaded driver \??\C:\Program Files\ASTRA32\ASTRA32.sys
Loaded driver \SystemRoot\System32\Drivers\ElbyCDIO.sys
Loaded driver \??\C:\WINDOWS\system32\drivers\GDTdiIcpt.sys
Loaded driver \SystemRoot\System32\DRIVERS\srv.sys
Loaded driver \??\D:\Apps\AntiVir PersonalEdition Classic\avgntflt.sys
Did not load driver \SystemRoot\System32\DRIVERS\ipnat.sys
Loaded driver \SystemRoot\System32\Drivers\HTTP.sys
Loaded driver \SystemRoot\system32\drivers\kmixer.sys

But these differences are pretty minor, it seems to (perhaps clueless) me, in the sense that their presence or absence shouldn't cause a boot failure.  So would you agree with me that the differences in the boot logs are a symptom of the problem rather than the cause?  I mean, what possible difference can these make in this situation?

The very last line in the failed boot log is:

"Loaded driver \SystemRoot\System32\DRIVERS\ndisuio.sys"

(the 3 lines following that in the good boot log are:
Did not load driver \SystemRoot\System32\DRIVERS\rdbss.sys
Did not load driver \SystemRoot\System32\DRIVERS\mrxsmb.sys
Loaded driver \SystemRoot\system32\drivers\wdmaud.sys)

There is nothing after the "ndisuio.sys" line in the log.  That could be an important clue, but I don't know what to make of it.  "ndisuio.sys" is described on the web as "a process belonging to the NDIS User Mode I/O (NDISUIO) NDIS protocol driver which offers support for wireless devices such as Bluetooth and the like." (But I'm not using wireless or Bluetooth).  However, another web site (http://www.iceteks.com/forums/index.php?showtopic=2445) suggests it might be suspicious and may be related to the Windows screen saver(??).  Again, none of my up-to-date anti-virus and anti-malware tools says there's anything wrong with any of those files (and if there were, you'd think they'd cause the same problem both ways).

I've read a hell of a lot of web pages about booting XP from a SCSI disk, but I haven't found anything particularly relevant and certainly nothing that helped me with this problem.  I saw a related web page ([URL="www.softwaretipsandtricks.com/forum/windows-xp/400-how-clone-windows-xp-installation-scsi-disk.html) that mentioned (among other things) "SID information", but that's related to user/logon id and user access security, so even if it's relevant, it's exactly the same in all situations, right?

Can anyone help me out?

Further, Random Details:

-- I have the latest driver and BIOS for my SCSI adapter.  I copied it (symmpi.sys) to the root of the SCSI boot partition and renamed it to Ntbootdd.sys just in case (but Microsoft assures me it should not be necessary in this situation).

-- My system BIOS is set to give boot priority to the SCSI disk first among the hard disks.  Total boot priority is set to Floppy, CD-ROM, Hard Disks (SCSI first, then SATA HD0, then SATA HD1).

-- When I boot from the XP install CD (with the SCSI adapter driver loaded along the way), when I go to the Recovery Console and type "MAP arc", it shows the SCSI boot partition as "multi(0)disk(0)rdisk(0)partition(1)", while the the other boot partition (the non-SCSI one) displays as "multi(0)disk(0)rdisk(1)partition(1)".  This is confirmed when I boot the Acronis Disk Director CD, which shows the disks in the arc order, so that the SCSI boot partition is always shown as the first disk and always given the (temporary) drive letter C.

-- The boot.ini file reads:


multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="SCSI Windows XP Pro rd(0)" /FASTDETECT /NOEXECUTE=OPTIN
multi(0)disk(0)rdisk(1)partition(1)\WINDOWS="SATA Windows XP Pro rd(1)" /FASTDETECT /NOEXECUTE=OPTIN

-- I've performed the recovery console's BOOTCFG /REBUILD, which produces the same results.  I've also tried FIXMBR on both the SCSI and the other partition.

-- I made sure that Windows didn't use the login window and that it would automatically start without the user having to select a username or password.

-- The XP boot partition on the SCSI disk is the first partition on the drive.  The partition attributes are: primary, active, and bootable.

System Configuration:

Motherboard: Abit IS7 -- Socket 478
Bus(es) : ISA AGP PCI IMB USB FireWire/1394 i2c/SMBus
MP Support : 1 Processor(s)  --  MP APIC : Yes
Processor: Intel Pentium 4(c) CPU 3.2GHz (Northwood), hyper-threaded
Chipset: Intel i865-ICH5 chipset (Intel 865/848 Springdale)
Storage Controllers: Intel(R) 82801EB/ER Ultra ATA (x2)
SCSI Storage Controller: LSI Logic 203320-R Ultra320 SCSI HDA
Total Memory: 1GB Micron/Crucial DDR-SDRAM
Video Adapter : RADEON 9200 Series
Audio: Auzentech X-Meridian 7.1

Hard Disk : WDC WD5000KS-00MNB0 SATA (466GB)
Hard Disk : WDC WD3200JD-22KLB0 SATA (298GB)
Hard Disk : CSC150GB 15K REFURBISHED SCSI Disk Device (137GB)
Hard Disk : WD External HDD Device IEEE 1394 SBP2 Device
CD/DVD : _NEC DVD_RW ND-2510A FW: 2.19

Operating System(s)
Windows System : Microsoft Windows XP/2002 Professional 5.01.2600 (Service Pack 2)


I tried using the XP install CD (with the specific SCSI driver asked for and loaded during the process) to perform a "Repair" installation of XP on the SCSI boot partition.

It proceeded fine through and including the point where it reboots to the new XP partition on disk (instead of CD), but eventually I recieved fatal error messages saying something like: "Setup failed to install the product catalogs. This is a fatal error" and including in the error log were lines such as "Setup failed to remove the product catalog SP2.CAT & DXBCA.CAT & DXXP.CAT", etc, followed at the end by "The signature for Windows XP Professional Upgrade is invalid. The error code is ffffb4g". (This last probably relates to the fact that I only have an XP Upgrade CD (from Win98) and not a full, fresh install CD.)

*BUT*, although it didn't fully succeed, it DID get to the point where setup had loaded all the necessary install files onto the SCSI disk and then booted to this minimal XP on the SCSI disk WITHOUT another XP installation visible (unless the install CD served this purpose).

That gave me an idea: I decided to boot up Hiren's Boot CD (8.7) and use the low-level MBR/disk tools to copy this apparently working boot partition's MBR and Track zero to floppy. Next, I re-cloned my SATA XP boot partition back to the SCSI disk. Then I went back into Hiren's and used those tools to restore the ostensibly good MBR and Track zero from the floppy. I was pretty optimistic, but unfortunately I got exactly the same results as before.

So I'm still stumped.

Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

skca54Senior EngineerCommented:
As a test, can you install XP fresh onto the SCSI disk and does it boot successfully? This should identify any hardware issues.
gern47Author Commented:
Well, you know that the SCSI disk already boots perfectly, right?  As long as it's not the only XP boot partition anywhere in the system.  Doesn't that demonstrate that there's no hardware issues?  Or am I missing something?

skca54Senior EngineerCommented:
OK. A fresh install should hopefully identify if the SCSI settings etc are causing any boot issues etc.
10 Tips to Protect Your Business from Ransomware

Did you know that ransomware is the most widespread, destructive malware in the world today? It accounts for 39% of all security breaches, with ransomware gangsters projected to make $11.5B in profits from online extortion by 2019.

gern47Author Commented:
Perhaps, but the SCSI settings are as nominal as nominal gets.  Controller 0, SCSI ID 0, LUN 0, Disk 0, etc., etc.  Virgin, latest SCSI miniport driver from the vendor.  RAID disabled.  The settings just can't get any plainer or more default than that.

Furthermore, although the XP installation repair failed in the end (see above), it DID boot perfectly from the SCSI disk after the initial process even though I had hidden the non-SCSI boot partition.  To me, that along with the other facts seems to be conclusive evidence that there are no hardware issues per se.

No, it seems to me that this is much more subtle than SCSI settings, and maybe has something to do with how XP assigns the C drive or an incompatible entry in the registry or maybe the wrong "System" file or something along those lines.

Now, I'd be perfectly happy to go through all the trouble of a fresh XP install to the SCSI if someone could tell me exactly what to save from that partition to transfer back to a clone of my working XP back to the SCSI partition that might solve this problem.  But, with respect, I'm reluctant to go through what you suggest without more of a firm basis that it would yield any relevant information.  At the least, I'll wait a couple of days to see if anyone has any other ideas to try first.  But thank you for your reply!

I had a scsi controller go bad and replaced it with a different adaptec.  Boot would get stuck with no option to install scsi drivers for new card.  Adaptec said either a fresh or repair windows install is necessary to get drivers for card installed, or put in dup of old card for booting along with the new card and then install drivers and remove old card.  The last approach worked.  You maybe have a similar problem - you're imaged copy won't have the scsi drivers but maybe you're other windows boot partition does?  Maybe install the scsi drivers before imaging so restoring the image on scsi has the necessary drivers.  I saw your note that you copied drivers to scsi partition but I'm not familiar with doing it that way.
Stephen CroftTechnical ArchitectCommented:
I had a similar problem a while back.

It occurs when XP / whatever MS OS doesnt see the SCSI card as the first bootable device, and wants to put its bootmanager on another drive.

Heres how i fixed it;

disconnect everything except floppy,cdrom,SCSI drive (ie disconnect any IDE / SATA / EXT drives you have)

in the BIOS, setup your pc to boot from SCSI device second, with CDROM first. this is important, and if you cant get the BIOS to boot to scsi, your stuck and you need the IDE drive there to boot from.

install Xp fresh, F6 your driver in on boot and blank the drive. XP should install w/out asking for any other drive to be available for it.

Let the install finish, do your drivers and so on and so forth.

Re-connect the IDE Hd, and double, no triple check your boot sequence in the BIOS. make sure that the IDE drive is not to be booted, ever.

and Voila, should work.

Had this issue with SATA on my main pc, and SCSI on my server (i got a few IDE drives in for storage.) Let me know the outcome!
gern47Author Commented:
mastoo: Both partitions are bit-for-bit identical, thus the specific, correct, working SCSI driver is installed in both partitions already.  And I have not changed the SCSI adapter, either.  It's the same one.

djxtreme: My system BIOS is ideal for my situation.  It not only expressly enables you to boot from any external device, it enables you to place the external device in any arbitrary position in the boot order (as described in my long-winded OP).  So my SCSI disk is already the first hard disk in the boot order (the floppy and CD-ROM precede it, but the SATAs come later).  This boot order and disk order is confirmed by all the data available to me that I can think to look for.

And while it may well be true that I might solve this problem by re-installing XP from scratch in the manner you suggest, that solution is completely and utterly UNACCEPTABLE!  It would be a nightmare, for several different reasons, just one of which is the fact that I have programs installed in my current system for which I no longer have the installers, and I refuse to forgo them.

Besides, I came here to Expert's Exchange specifically so that I would not have to follow such a brute-force solution.  We both know that whatever unique information is stored on the SCSI boot partition by a fresh XP install can be extracted, copied, and then transferred to a cloned copy of my current system.  With respect, what I'm here looking for is someone who can tell me just what that information might be, or at least provide a less brute-force solution.  But I thank you for your reply.

Stephen CroftTechnical ArchitectCommented:
Gern47 - As I understand what you are trying to attain, XP specifically tags itself to the SCSI / IDE controller that it is installed on. This is to stop people breaching copyright laws primarily (although they probably wont admit it), so it isnt just that easy to "install the correct drivers and it will work" as XP is looking for a Specific drive that is plugged into a specific controller.

If a full reinstall is too "brute" for you, then perform a repair installation of windows in my walkthrough. It is enough to repair the MBR / Bootcfg, and refresh XP's record of what controller card your harddisk is plugged in on.

Just one question for you however.

With the SCSI install that will boot with the IDE drive in (and therefore the IDE drive is probably storing either the MBR, or more possibly the Bootmanager that is included with XP), have you tried  the following?
unplug the IDE drive, booting to a XP cd (and loading the F6 drivers).
Select recover console
Select your XP Install (if it doesnt see one, this method wont work).
Type a combination of the following commands
boocfg /scan
bootcfg /repair

see if that does anything for you. Ive a feeling that if the CD picks up your installation then it should be able to repair the bootmanager.

And next time, a more courteous reply would be appreciated. I only told you of an experience that I had, and how I repaired it in an attempt to shed some light into the issue you were having. I accept your thankyou, but still feel the overall message was blunt and inconsiderate of the fact that Experts Exchange is full of people giving up their free time to try to aid you. If you are so sure there is an answer out there, im sure an extensive hour or two of googling would give you that answer.

gern47Author Commented:
djxtreme: I regret that you found my reply too blunt or unappreciative.  It was very far from my intent to offend, I assure you!  I very much appreciate all replies, and I completely recognize that I'm in no way entitled to anyone's time or help.

But please understand that I had already explored all the suggestions given here thus far (including your most recent ones) -- as I generally described in my OP -- long before I posted this inquiry at Expert's Exchange.  I had also posted this inquiry previously elsewhere at free help sites, such as CNET and XP Annoyances and others, but had received nothing helpful there either (those replies, too, had focused on  solutions that were either unacceptable in my situation (e.g., re-install XP fresh from scratch), or did not work (e.g., "repair" install).  So, as I indicated respectfully in my previous reply, I came here to Expert's Exchange and paid my fee hoping to find someone who was truly an expert in this unique, particular area (which is not in any way to imply that you're not an expert in any number of areas).  After all, the site is named "Expert's Exchange".  I did not anticipate that asking for somewhat more expert and detailed assistance might offend anyone, and for that, I apologize.

Moving on, in your first paragraph, you identify the issue that I've long thought was a key to all this: the specific, unique information XP apparently stores on the target partition during a fresh install that must be transferred to my cloned system for it to boot fully.  The question remains, though: Where is this information and how can I identify, copy, and transfer it to my cloned system?  This is precisely why I think I need an expert.  (And please note that I described such attempts in my OP).

Now, I certainly accept the idea that Microsoft would take steps to attempt to minimize copyright violations.  But here's the thing: Microsoft freely provides information on how IT professionals can perform bulk, automatic installs of XP throughout the enterprise (not that I can follow all this often arcane discussion).  To me, that strongly implies that EXTREMELY controller/disk specific information is not required, or I don't see how such bulk distributions could work.  So there still seems to be an extremely high probability that what I'm trying to do can work WITHOUT requiring a clean install of XP on the SCSI partition.

You further suggest a repair install might solve my problem.  But in my OP, I describe my attempt to perform a repair install and noted that it failed and why. Perhaps you missed it in all those words. (I guess I just have to accept the fact that people rarely actually read a long OP, even here).  I further note there that I attempted to copy the MBR and Track 0 off this partially repaired -- but successfully booting -- system and transplant it, but without success; the exact same symptoms were seen.

And although I admit that I did not detail each and every line of exploration I pursued in my OP (it was long enough already), I should let you know that I'd already tried all of the commands in your list and much more before posting (please see, for example, my reference there to "I've performed the recovery console's BOOTCFG /REBUILD, which produces the same results.  I've also tried FIXMBR on both the SCSI and the other partition").  I believe in going as far as one possibly can on one's own and with the help of reference material on the web before asking for assistance, and I have done just that on this occasion.  I'd read several scores of web pages relating to these issues, but after spending a couple of weeks doing so and not finding what I needed, I decided to post my question at various help sites, eventually landing here when no one else could help elsewhere.

But to demonstrate my respect for your time and assistance, I tried those commands again just minutes ago.  Unfortunately, nothing's changed.  The exact same symptoms remain.

I don't suppose you have any other suggestions or can suggest where else I might turn?

Stephen CroftTechnical ArchitectCommented:

my apologies for not picking up on you already having done that. I did completley read the thread, however it was lateish when i replied and my head obviously wasnt 100% in place.

I have re-read the thread, and have had a few other thoughts.

I didnt pick up on it before, but you say your 2nd HDD is a SATA? Is this off a onboard controller, or do you have a pci (or other type) of expansion card that this is plugged into? Also, when you POST your PC does the SCSI controller or the SATA controller post first?
I take it when you sucsessfully boot XP with the 2nd HDD in, it is assigned a non-C: letter, ie D:
Going from the following article seems to be what you are having;
I know this is for 2000, but basically It looks similar to what you are doing. The problem is that you are changing your boot drive's letter, and XP doesnt know where to look for its files/folders to enable it to boot.
Going from what you have said, the install is a clone of your SATA install, correct? If this is so, this explains your problems, and ill summarise below;
a) XP stores the GUID of the drive it was installed to, to ensure that it always gets the correct drive letter in the event of a new HDD installation, in this case this is C: on your SATA install
b) If you duplicate this install via a Clone (acronis), then xp still see's your original drives GUID as being the one that should get c:. therefore when you boot, your new drive with a DIFFERENT GUID gets another drive letter. D:.
c) this causes xp to halt after the auto-login, and never display the desktop. this is because xp is looking for c:\windows\system32\userinit.exe and some other files for it to boot sucsessfully.
d) putting your SATA drive in works, but only because it assigned C: to teh SATA, and your SCSI boot can find c:\windows et al.

heres a rough guide to fixing it. your going to need a second pc, or a copy of barts PE with a registry editor installed. I use a program called UBCD to have this, although finding a copy may be a bit awkard due to copyright laws.


boot the pc that is having the problems, and let it get to the bit where it sticks. leave that and go to the 2nd pc. using a command prompt,  navigate to \\BROKENPC\IPC$. the command in dos will be something around "NET USE \\PROKENPC\IPC$ /user:administrator* . feel free to double check this command. Then open REGEDIT and open another pc. in here pop in your pc name for the BROKENPC. this should now give you your registry for the brokenpc.
Pop disk in BROKENPC. open up the installed regedit, and you should have the registry for the brokenpc.
2) change the following (note this is copied from the microsoft KB)

Change from:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Current Version\Winlogon\Userinit:Reg_SZ:C:\WINNT\system32\userinit.exe
Change to:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Current Version\Winlogon\Userinit:Reg_SZ:userinit.exe

now try a reboot from the SCSI, with the SATA disabled. If this works, but your drive is still not C: follow the following KB instructions (which i shall paste anyway);


Log on as an Administrator.
3. Start Regedt32.exe.
4. Go to the following registry key:
5. Click MountedDevices.
6. On the Security menu, click Permissions.  
7. Verify that Administrators have full control. Change this back when you are finished with these steps.
8. Quit Regedt32.exe, and then start Regedit.exe.  
9. Locate the following registry key:
10. Find the drive letter you want to change to (new). Look for "\DosDevices\C:".
11. Right-click \DosDevices\C:, and then click Rename.

Note You must use Regedit instead of Regedt32 to rename this registry key.
12. Rename it to an unused drive letter "\DosDevices\Z:".

This frees up drive letter C.
13. Find the drive letter you want changed. Look for "\DosDevices\D:".
14. Right-click \DosDevices\D:, and then click Rename.
15. Rename it to the appropriate (new) drive letter "\DosDevices\C:".
16. Click the value for \DosDevices\Z:, click Rename, and then name it back to "\DosDevices\D:".
17. Quit Regedit, and then start Regedt32.
18. Change the permissions back to the previous setting for Administrators (this should probably be Read Only).
19. Restart the computer.

This is based on the correct drive letter you want being C: and the incorrect one assigned being D:

Try that, let me know the outcomes.

BTW, it MAY be worth trying the step 2 first, as getting that to work via the networked registry editor should solve your problems. but the first one would be a quick "hack" to get your xp installation booted.


gern47Author Commented:
WOW!  This seems to be EXACTLY what I've been looking for!! Great, great, great!  Thank you so very much, djxtreme!

I'm eager to try your solution, but I thought it would be best to discuss this a bit further and for me to answer your questions first.

You write:

"1) I didnt pick up on it before, but you say your 2nd HDD is a SATA? Is this off a onboard controller, or do you have a pci (or other type) of expansion card that this is plugged into? Also, when you POST your PC does the SCSI controller or the SATA controller post first?"

Yes, my other (non-SCSI) disks are SATA.  The controller is on-board.  As for the post order question, I'm afraid I just can't tell for sure.  When it first starts, two lines of text that seem to list my two SATA drives flash by so quickly I can't quite make them out.  Then the SCSI adapter's BIOS loads, THEN I see a full post of all my devices, including the SATA drives.  So I'm not really sure.

You then write:

"2) I take it when you sucsessfully boot XP with the 2nd HDD in, it is assigned a non-C: letter, ie D:"

Yes.  In my case, it is assigned drive letter O:  Note, though, that when I boot WITHOUT the SATA boot partition visible, Windows DOES give the SCSI boot partition drive letter C.  But then it just doesn't boot fully, getting stuck as I describe in the OP.  Note, though, that this does NOT match the description given in the Win2000 KB article (http://support.microsoft.com/kb/249321).  So it may not apply here.

You then write:

"Going from what you have said, the install is a clone of your SATA install, correct?"

Yes.  And your summarization of what's going on seems to me to be very likely spot on.  Thanks again!

But I'm afraid your next set of instructions regarding the remote networking is new and confusing to me.    I have other XP (home edition) computers in my home network to use for this, but they're all on a wireless network.  Do you think that makes any difference?  Right now, none of them are sharing anything -- the wireless connection is strictly for wireless Internet connections.  What do I need to enable and set up for me to follow your instructions?

Or are you telling me that using the Bart PE will allow me to bypass the remote networking instructions?

(more later, I have to go)

Stephen CroftTechnical ArchitectCommented:
The network solution is only going to work on a wired network - as the network needs to be live when your SCSI install is halted on the blue screen.

and yes, using some form of a Bart PE disk with a registry editor installed on the cd will allow you to edit your registry from a live cd.

try this site


for an explanation of how it works.
get Bart PE installation from

please note you will need a XP cd of some sort, im not sure if your upgrade disk will work. Either borrow one from a friend (since you are not using the licence, and you own a XP Pro/Home licence this is legal as far as i know), or use one of the XP Home cd's.

to answer your other Q's (I did the Bart PE one first as that is the most important IMHO),
this can be ignored now. since we seem to have hit golden on the second idea of mine, we shall follow that through . FYI, if your SATA drives are showing, then SCSI then your SATA cards are "posting" first. however it seems as you have a onboard controller, that the motherboard is using a enhanced SATA mode so that XP will see them as IDE drives. again you can ignore this point completley :)

So let me get this right.
When you boot the SCSI with the SATA in, you get a c: and a o: drive.
could you double/triple check what drives are getting what letters. go into disk management under computer managent (right click my comp and manage) and right click each disk (disk0 and disk1) and note the make/model of the two dribves there. post them here. I am sure you have done this, but please just one more time so I can see it clearly.
Also, could you clarify why your drives go c: ----- o:. when I have had problems before the most I have seen a drive move is 2-3 letters, and that is because of DVD/CDROM drive. is there drives inbetween?

I seriously belive that although the MS KB articles are not 100% for what you have, editing the registry and changing the GUID's for the drive that obtains letter C:/O: should work. This may take a little fiddling though as we need to figure out what path exactly your SCSI is looking for to boot.

One other thing I am curious about is what drive is actually booting when both are in. Sounds daft, but because of all this drive letter swapping, im not 100% sure what drive is active when it sucsessfully boots. It may be booting off the SCSI, but utilising the install off the SATA, or visa versa. I may be wrong, but we need to 100% (again double and triple check) assertain what partition is active.

This test i propose to find this out is assuming that your SATA drive boots independantly. If it doesnt, the dont follow it
1) boot both drives
2) change something that relates to the registry. a file / folder wont make much difference here IMHO, so just edit the registry, navigate to anywhere you can remember (HKLocal Machine - Software - Microsoft - Windows - Current Version would do) and add a key in with a random name. DO NOT EDIT ANYTHING IN THIS REGISTRY TREE. Call the key something like "Test" with a value of 1. Be wary that although this shouldnt cause any knock on effects, if a flock of birds crash into your lounge after changing it, it aint my fault (lol)
3) boot the SATA w/out the SCSI in. check the registry. If the key is there, its booting the SATA install for REG. If the key aint there, its the SCSI.

Again, post results.

Last thing I want you to check before I advise you to 100% go ahead (at this point still hang on, its wise to do so until we are 200% sure about doing this).

check the following key in three scenario's
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Current Version\Winlogon\Userinit:Reg_SZ:C:\WINNT\system32\userinit.exe


its the last bit were interested in, the USERinit:Reg_SZ: onwards. lets see if these are different, then we can advise you what to change and what drive letter to change it to.

Glad we are hitting on the right road. thing that worries me about the other forums especially that you posted it on, is a google on "Changing Drive Letters" pulled up that KB article i referenced pretty much at the top. If soneone had bothered to read and think first, or at least try with the intention of delving deeper if needed (ala what I did), then you would have been in this situation already. Guess it makes sense to come to Experts Exchange more often lol ;)

Stephen CroftTechnical ArchitectCommented:
one last thing; a word of warning.

although we seem to have made a massive amount of progress in the last few posts, I feel as though I am still missing something - something just isnt sitting "right" in my head aobut this. Im hoping if you can answer my questions I may be able to figure out what that is, and see if it is going to interfere.

In the mean time, DO NOT UNDER ANY CIRCUMSTANCES try our proposed solutions yet. Feel free to boot the Registry and "look" to see what the settins are ATM, but do not change. If you do it wrong, you may make it worse.

Sorry if i have repeated myself, but I want to make sure we are all on the same hymn sheet ok?

Look forward to your response.

gern47Author Commented:

The remote networking seems to be at least minially working.  If I do a "NET VIEW" command at the remote computer, it does list this computer as a shared resource.  However, if I try the following commands:


I get "System error 53 has occurred.  The network path was not found".

If I try "NET USE \\SCSI_PC\IPC$ /user:abc*", I get "The user context supplied is invalid".

gern47Author Commented:
Oops.  I didn't see your previous two posts before adding my previous one.  I will take time out now to read them carefully and post back as soon as I'm able.  Thanks!

Stephen CroftTechnical ArchitectCommented:
if you wish to try net use, try the following

net use \\SCSI_PC\IPC$ /user:administrator [PASSWORD FOR ADMIN ACCOUNT]

it may/may not work.
gern47Author Commented:
Okay, reporting back, sir!  You wrote:

So let me get this right.
When you boot the SCSI with the SATA in, you get a c: and a o: drive.
could you double/triple check what drives are getting what letters. go into disk management under computer managent (right click my comp and manage) and right click each disk (disk0 and disk1) and note the make/model of the two dribves there. post them here. I am sure you have done this, but please just one more time so I can see it clearly."

ANSWER: When I boot from the SATA boot partition, I see both drive letters C and O (and other which we can ignore), with the SATA partition always getting letter C.  When I boot from the SCSI partition, *IT* recieves driver letter C, but since it won't fully boot, I don't know what or how other letters are assigned.

Here is a link to a jpeg of my Disk Management display:

Ignore the "unknown partitions".  They are only assigned drive letters if and when theyre specifically mounted, which is not the usual case.  Here is the specific disk info:

Disk 0 : WDC WD5000KS-00MNB0 SATA (466GB)
Disk 1 : WDC WD3200JD-22KLB0 SATA (298GB)
Disk 2 : CSC150GB 15K REFURBISHED SCSI Disk Device (137GB)

Note the oddity wherein Disk0/Part0 (the working SATA boot partition) is labeled "Boot" while Disk2/Part 0 (the SCSI boot partition) is labeled "System".  Strange, huh?

You then ask:
"Also, could you clarify why your drives go c: ----- o:. when I have had problems before the most I have seen a drive move is 2-3 letters, and that is because of DVD/CDROM drive. is there drives inbetween?"

As you can see from my disk management display, there are several other drive letters assigned and some I have reserved for possible mounting of the typically unmounted partitions.  I used the official disk management tool's "Change drive letter..." feature for these, bypassing the normal sequential drive letter assignments.

You ask:
"One other thing I am curious about is what drive is actually booting when both are in. Sounds daft, but because of all this drive letter swapping, im not 100% sure what drive is active when it sucsessfully boots. It may be booting off the SCSI, but utilising the install off the SATA, or visa versa. I may be wrong, but we need to 100% (again double and triple check) assertain what partition is active. .... "

I very much agree that there may well be something like this going on.  But I'm afraid I don't quite see why we need to create a temporary registry key for this.  Could you explain?  What I've done instead is to create a text file named INFO.TXT on the root of each partition, the file on the SATA partition contains "SATA partition" and the file on the SCSI says "SCSI partition".  That way, when I boot I can check the file specifically named "C:\INFO.TXT" and determine which is which. I can also start a CMD window and look at the prompt or see the value of the environment variable %SYSTEMROOT%.  But if adding that reg key is the right way, I'll gladly do it!  Just say the word.

Stephen CroftTechnical ArchitectCommented:
Ok, the plot thickens.

Could you unplug your SCSI and boot, and take another screengrab. Im interested where the Boot / System markers go then.

Also, in answer to your registry question, its upto you. Id put a key in the registry, and id prefer you to.

reason behind this is a file in the root doesnt prove what OS you are booting from when you have SCSI and SATA installed. if you are booting off the SATA userinit.exe / registry, then putting a SCSI file wont do nothing. especially when you boot to SATA only (no SCSI), and suprise suprise theres a SATA txt file ;)

Im puzzled about the boot part of the system/boot flags being on the SATA drive.
Im a bit worried that your acronis hasn't cloned over the bootmanager. Saying that, if it hadn't your SCSI wouldnt boot at all, nevermind get to where it does.

Try those, post results, lets see what we can come upto.

Also could you post the contents of your Registry path I asked?

check the following key in three scenario's
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Current Version\Winlogon\Userinit:Reg_SZ:C:\WINNT\system32\userinit.exe

try this on your SCSI + SATA boot, and the SATA-only (disconnect the SCSI drive) boot I have asked you to do.

Also, are you GMT? if so what time you on 'till?
Stephen CroftTechnical ArchitectCommented:
Hiya there.

Just a little update.

Got into work today, and the workshop engineers had a problem. low and behold it was the case of a boot drive clone going like yours.

decided to put what we have discussed to test, and followed the method I suggested (from within windows, as with both drives in, it booted to the new drive).

heres what i did;

1) took out the c:/windows/system32 before the userinit.exe in HKLM/Software/Microsoft/WindowsNT/CurrentVersion
2) renamed the keys in HKLM/System/MountedDevices for C: to O: and E: (the drive I wanted to boot from) to C:.
3) rebooted with a drive C: (the new one) and O:( the old one).
4) deleted all partitions on O: and formatted, rebooted with C: being the only boot drive and it working 100%.

so looks like we on a winner :)


Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
gern47Author Commented:
Sorry for the delay in responding.  I'm quite excited about your last post!  *GREAT*!

I'm looking forward to tying it, and even though I'm gonna be pretty busy for a while, I expect to try it this evening (US Eastern).

But I want to make sure I know what I'll be doing.  Do you think you might be able to find the time to elaborate more on the solution given in your last post?  Perhaps a little more of a cookbook?  I'm familiar with editing the registry and so forth, but I'm afraid I'm a little bit unlcear on just what I need to do in full.  I know I'm asking a lot, so thanks in advance!

Stephen CroftTechnical ArchitectCommented:
Not sure how much more i can elaborate.

I booted with both drives (and got a C: and a E: partition.) slightly dissimilar to you, my Boot wasnt specified on any partion. however this was on a Dell pc, so I dont expect anything different.
I went into the registry editer (start - run - regedit - ok) then browsed to;
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Current Version\Winlogon\
and changed the Userinit variable to remove the c:\windows\system32 so it was just userinit.exe
went into the 32-bit registry edit (start - run - regedt32 - ok)
navigated to;
Renamed the string (right click - rename) \DosDevices\C: to \DosDevices\O:
                                                                  \DosDevices\E: to \DosDevices\C:

Exit registry and shutdown.

Now at this point I booted with both drives in, and blanked the old C: drive, but I would reccommend you boot with JUST the SCSI in (take both SATA drives out) and see the results.

If it works, shutdown and plug in both SATA and boot again. Check your SCSI is on C:, then check your Disk Management, and see what it's assigned to the old SATA boot partition. if its just (Healthy), try blanking it (if this is what you want), and reboot.

I look forward to the results :)
Stephen CroftTechnical ArchitectCommented:

unless you get a permissions issue. If you do I will post how to solve that (dont want to confuse you)
gern47Author Commented:
* IT WORKS!! *  Great, great job djxtreme! You're a hero!

Here's how I followed YOUR solution:

(1) I booted from the SCSI partition with BOTH boot partitions visible (all disks plugged in).

(2) I ran regedt32 (actually my copy of Registrar Registry Commander, but they're equivalent and both work)  to change the
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Current Version\Winlogon\Userinit

value from:




and exited the registry editor.

(3) ran "regedit" (the 16-bit version), then navigated to:


and changed the keys:

\DosDevices\C:    to   \DosDevices\Z:
\DosDevices\O:   to    \DosDevices\C:

then exited the registry editor, then shut down.

(4) I booted up the Acronis Disk Director 10 CD, then

Marked the SATA boot partition "Hidden"  (this is easier than removing/unplugging the SATA disk entirely)

Exited Acronis Disk Director

(5) Rebooted from the SCSI boot partition, now hard-assigned to drive letter C


It booted perfectly, WITHOUT the other (SATA) boot partition visible!

(6) Although not mentioned in either your or Microsoft's solutions, I felt it was necessary to:

run regedt32 (in my case Registrar Registry Manager) and RESTORED the

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Current Version\Winlogon\Userinit

value to


because it seemed to me that without this step, userinit.exe wasn't guaranteed to run (since without thr rest of the path, I thought it might try to look for it at the root of the partition, which does NOT contain userinit.exe.

(7) I rebooted again with that in place, and everything still works PERFECTLY!


Thank you so very much djxtreme!  Well done, and I greatly appreciate your patience in helping me find a better solution than anyone else had offered!

Stephen CroftTechnical ArchitectCommented:

Glad it worked :P

Just FYI, windows doesnt matter about the userinit.exe registry entry. What you changed it to forced windows to look in its default folders for userinit.exe, whereas the defaults forced it to a specific folder. not that it makes any difference anyway.

Let us know if you require any other help with anything else, and for now, goodbye!
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.