FAT32 slave causes XP not to boot

[RBBRMADE]

I have a system with 2 hard drives.
WinXP in the master (NTFS), and the slave is an older drive with Win98 (FAT32) loaded.
The system use to boot just fine and recognize the slave and access it, etc.
Now the system will not boot with the slave attached.
I have tried the slave drive in a different system with XP, and it will also NOT boot!
I put the slave in a system running Win98, and it booted. The slave was recognized, and access was no problem!

What the heck?

Any ideas appreciated!
Thanx,
Ron

 

[MrChad]

What do you mean by "not boot"? What type of error message do you get?

 

[biostud]

In BIOS under boot menu it probably is set to boot from HDD1.

When you have one HDD in your computer even if it's HDD0 it will boot from it, but when you put in the other drive, your slave drive will be HDD1 and it will try to boot from it. So set your boot drive to HDD0 in the bios Boot menu.

That would be my guess.

 

[RBBRMADE]

Good try, guys, but I got all those right.
I get the Windows splash screen, but never get the 'click on username' screen to enter windows.
In the Win98 box, it still boots right up.
nothing was changed when it all of a sudden stopped working in a XP box!

Ron

 

[thegorx]

well of the top of my head trying to look over the facts you've given as I understand them
I suspect the hard drive maybe failing
maybe the drive works with the windows 98 system because the drive controller is slower.
I often recovered data of failing drives using older systems or external usb enclosures
which I have better luck getting the drive to read than from that faster drive controllers on newer systems.

I guess you should try a boot disk with your newer system to see if the old drive is readable
or even test the drive with a boot disk utility program from the hard drives website

 

[RBBRMADE]

Originally posted by: thegorx
well of the top of my head trying to look over the facts you've given as I understand them
I suspect the hard drive maybe failing
maybe the drive works with the windows 98 system because the drive controller is slower.
I often recovered data of failing drives using older systems or external usb enclosures
which I have better luck getting the drive to read than from that faster drive controllers on newer systems.

I guess you should try a boot disk with your newer system to see if the old drive is readable
or even test the drive with a boot disk utility program from the hard drives website

I have never heard of such a thing, but that makes more sense then anything. I consider myself pretty good at reasearching on the web, and when I cannot find an answer for something like this, it drives me nuts. Since it did not seem to be a known issue, I figured I would just have to run into someone that knows.... You having first hand experience is super.
Thanx very much for the input!
Ron

 

[thegorx]

yeah, it sounds like you tried everything that would suggest another possible answer
such as a corrupt registy or a problem with your windows xp or your system.

so you'd have to assume that it's the drive, since you can recreate the problem on another XP system
and your original system was working fine up until a point.

unless there is something being over looked

 

[Sianath]

If your XP OS boots without the slave attached, then the problem is isolated to that other disk.

What would account for this is if the other disk has a valid MBR and is marked active. The POST process will locate the first enumerated disk and attempt to read the MBR. If there is a valid MBR, that MBR boot code will attempt to locate an active partition on the disk. It will pass control to the boot sector of the active partition (on an NTFS system, that's where NTLDR is located) and boot proceeds from there.

If your slave disk has a good MBR and an active partition, for better or for worse, we'll try and boot to it. Are you sure your "slave" disk is set as a slave via jumpers on disk? If this repro's in multiple machines, the disk is getting enumerated first for some reason...

 

[RBBRMADE]

Originally posted by: Sianath
If your XP OS boots without the slave attached, then the problem is isolated to that other disk.

Are you sure your "slave" disk is set as a slave via jumpers on disk? If this repro's in multiple machines, the disk is getting enumerated first for some reason...

The machine used to work just fine with the exact same set up. Nothing had been changed when it decided to stop booting.

Thanx,
Ron

 

[MadRat]

Sounds like the FAT32 drive's controller is unable to cope with XP's autodetect feature. Its probably unable to negotiate a common speed that is compatible. Just one of those 60k original XP bugs that most people never have problems with, and perhaps SP2 will fix.

 

[Sianath]

If it were a hardware issue with the controller like you describe, the disk NEVER would have worked in the machine with XP. He stated in his very first post that it used to work just fine.

I'd love to see the MBR of that disk....

 

[MadRat]

No, controllers can have too long of response times for XP to recognize them. Faster XP machines show this more often I've heard because MS decided to use a CPU cycle count for the timer and not do it in real time.

 

[Smilin]

Interesting. Where did you pick that up from? Also, please explain what XP's autodetect feature is and how it relates to this common speed you are talking about. I'm always up for some new info. Thanks!

 

[MadRat]

Its been a problem with Windows in successive generations. Go try to load something new like a 3Ghz P4 on an old Windows, like Win95 or Win98FE. You will understand.

The controllers may take too long to initialize, so long that XP just decides nothing in hooked onto the channel.

 

[VirtualLarry]

Originally posted by: Smilin
Interesting. Where did you pick that up from? Also, please explain what XP's autodetect feature is and how it relates to this common speed you are talking about. I'm always up for some new info. Thanks!

The IDE controller driver timeouts and related code was changed in XP. So much so that many users started seeing "delayed write failed" due to nothing more than the IDE controller driver experiencing timeouts in XP, not actually write errors. I believe that the delay was increased in SP1, to bring it back more in line with the codebase in W2K's IDE controller drivers.

Don't forget, too, that WinXP introduced a specific IDE port/miniport driver architecture, whereas NT/W2K simply treated them as a special-case of the SCSI port/miniport driver. Many PCI IDE RAID controller mfg's had to make some choices about which driver model they would support under XP. CMD IDE controller chips emulate regular BM-IDE controllers in hardware, so could be supported in non-RAID configurations using the IDE port driver in XP, but still use the SCSI port driver architecture to implement their RAID driver. Promise, on the other hand, uses a SCSI driver model all the way.

Btw, to the OP - are you trying to boot a Win98se installation, off of a HD that is not the primary (first HD) boot device in the BIOS? The bootloader in DOS and Win9x will only operate properly on BIOS disk 0x80. This means that DOS and Win9x will only boot off of the first physical HD (as set by the BIOS fixed-disk device boot order).

Note that the BIOS disk number is actually stored in the BPB of the DBR. If you move HDs around, containing FAT filesystems, you may need to "SYS C:" (or whatever drive letter corresponds to the moved HD), after booting from a floppy. This will re-write the DBR, including the BPB, with the correct BIOS disk number for that drive.