Boot from SCSI drive: Driver?

[DWalker]

If a SCSI or a SATA driver is required to read data from a SCSI or SATA
disk that is the boot disk (and the C drive), where is this driver
stored... and how does Windows know enough to read the SCSI or SATA disk in
order to read the code from this driver file?

It seems that Windows would need the driver code loaded before it can read
the driver code off of the disk, which is a catch-22.

Does the same apply to the NTBOOTDD.SYS file (or is this just the SCSI
version of the driver file)? If NTBOOTDD.SYS is required on the C drive of
a SCSI drive, and it contains the code to read the SCSI drive, how does a
Windows system load this SYS file?

My system has a SATA drive as the C drive, and I don't have an NTBOOTDD.SYS
file in the root of C (and I can see hidden and system files). I also
don't see the SATA driver anywhere, but it's probably buried in System32 or
somewhere like that.

Still, I am confused how Windows can read a disk to get a driver that it
needs to have in order to read the disk.


David

 

[Jerry]

Usually, the necessary driver for the SATA drive is installed during the
installtion of Windows itself, when the user is asked/required to press F6
and have the floppy in the floppy drive from which the Windows install
routine reads the floppy and installs the drives. This is how Windows knows
about and loads the driver when it starts.

 

[DWalker]

All of Windows resides on the disk; none of it resides in the
motherboard or anywhere in the ether, as far as I know.

Windows has to load the driver OFF OF the disk that contains the DLL or
SYS file *for the driver itself*. If Windows can read the SATA or SCSI
disk to GET the driver, why does Windows need the driver?

Can you see what I'm asking? If the SATA or SCSI disk is the only disk
in the system, then Windows couldn't read THAT DISK to read the driver,
even if that driver was available when Windows was installed (with the
F6 option).


David Walker

 

[Jim]

All of Windows resides on the disk; none of it resides in the
motherboard or anywhere in the ether, as far as I know.

Windows has to load the driver OFF OF the disk that contains the DLL or
SYS file *for the driver itself*. If Windows can read the SATA or SCSI
disk to GET the driver, why does Windows need the driver?

Can you see what I'm asking? If the SATA or SCSI disk is the only disk
in the system, then Windows couldn't read THAT DISK to read the driver,
even if that driver was available when Windows was installed (with the
F6 option).

No, you don't understand. When you press F6 (or whatever) you insert a
floppy disk in the drive.
This floppy disk contains the missing driver and associated files. The
installation software loads the driver into
memory so that the installation can proceed.
Jim

 

[DL]

The driver is loaded/installed, during the install process, via F6 before
win starts to load or install on the disk
Win cannot see any hd untill the driver is loaded

 

[John John]

It's done by the Nt Boot Loader, ntldr.

John

All of Windows resides on the disk; none of it resides in the
motherboard or anywhere in the ether, as far as I know.

Windows has to load the driver OFF OF the disk that contains the DLL or
SYS file *for the driver itself*. If Windows can read the SATA or SCSI
disk to GET the driver, why does Windows need the driver?

Can you see what I'm asking? If the SATA or SCSI disk is the only disk
in the system, then Windows couldn't read THAT DISK to read the driver,
even if that driver was available when Windows was installed (with the
F6 option).


David Walker

 

[DWalker]

No, you don't understand. When you press F6 (or whatever) you insert
a floppy disk in the drive.
This floppy disk contains the missing driver and associated files.
The installation software loads the driver into
memory so that the installation can proceed.
Jim

I understand this part DURING INSTALLATION, but during the next reboot,
how can Windows read the SCSI hard drive that contains the SCSI driver
code, without having already read the SCSI driver code off of the SCSI
hard drive?

David

 

[DWalker]

The driver is loaded/installed, during the install process, via F6 before
win starts to load or install on the disk
Win cannot see any hd untill the driver is loaded

You have said the same thing that Jim said.

If Windows cannot see any HD until the driver is loaded, then how can it
boot THE NEXT TIME after the install? Especially if it needs the driver
code for the SCSI disk, in order to read the SCSI disk that contains the
SCSI driver?

David

 

[DWalker]

It's done by the Nt Boot Loader, ntldr.

John

John: ntldr might be on the SCSI disk drive. Especially if that is the
only disk in the system.

How can Windows read the SCSI disk without a SCSI driver? And if the SCSI
driver resides inside ntldr, which is on a SCSI disk, how can Windows boot?

Is the motherboard smart enough to read ntldr off of a SCSI disk (during
the next reboot, not during Windows install) without needing the SCSI
driver itself?

If that's the case, why is the SCSI driver needed at all?


David


P.S. I don't understand why my question is so hard to understand... It's
like in the old days, where if you accidentally compressed the DLL file
that contained Windows 95's decompression code, Windows 95 couldn't read
the code to know how to uncompress the DLL.

Or if you send someone a Zipped file that contains an unzipper program...
you need to unzip the file to install the program.

 

[John John]

The question isn't hard to understand. Very quickly here is the
(condensed) low down on how it happens.

1- The boot order and boot device is set in the BIOS of the computer.
Even if it's a SATA or RAID controller the BIOS *has* to be able to see
and read from the device to boot the computer. That is not specific to
Windows, it applies to any operating system.

2- With regards to booting fixed MBR disks the BIOS reads the Master
Boot Record on the disk and loads it into memory then the BIOS passes
the boot process to the Master Boot Code. The MBR contains the
partition table for the disk and a small amount of executable code
called the Master Boot Code, the Master Boot Code contains the necessary
instructions to continue the boot process.

3- The Master Boot Code scans the partition table and locates the
active or system partition and loads sector 0 (Partition Boot Sector) of
the active partition into memory and then executes the partition boot
sector code.

4- The partition boot sector code locates the operating system loader
and loads it into memory and launches the execution of the operating
system loader. Up to this point the BIOS, Master Boot Code and
Partition Boot Sector Code have been responsible for the boot process.
This happens regardless of the file system on the disk and regardless of
the type of disk controller (IDE, SATA, RAID) and regardless of the
operating system to be loaded.

5- As stated in step 4, the partition boot sector code executes the
operating system loader, in the case of Windows NT/2000/XP the operating
system loader is ntldr (short for nt loader). Ntldr contains a mini
file system driver that enables it to read the file system on the disk
and enables it to load the necessary files to load Windows. Although it
is universally accepted that ntldr is a part of Windows, in a pure sense
it really isn't. Ntldr is a DOS type program that is responsible for
*loading* Windows. While it is doing its job Windows is not yet
started, Windows will be started *by* ntldr.

6- Ntldr calls on NTDETECT.COM, another DOS type program, to gather
information about the computer hardware. NTDETECT.COM will gather a
list and that list will be used to create the HKEY_LOCAL_MACHINE\
HARDWARE key. At this point Windows is not yet started, the boot
process is still being handled by ntldr.

*Here is the answer to your question* :

"At this time Ntldr scans all of the services in the Registry subkey
HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services for device
drivers with a Start value of 0x0, which indicates that they should be
loaded but not initialized. Device drivers with these values are
typically low-level hardware device drivers, such as hard disk device
drivers."

7- At the same time as events in step 6 were happening Ntldr began
loading NTOSKRNL.EXE but the boot process has not yet been passed on to
Windows. Ntldr will only pass the boot process after it has finished
loading drivers with an 0x0 value.

And that is why Windows knows how to use SCSI/SATA/RAID drivers, it
knows because ntldr loads boot device drivers (0x0) for Windows before
it actually loads Windows.

John

 

[DWalker]

Thanks. A few comments interspersed below.

The question isn't hard to understand. Very quickly here is the
(condensed) low down on how it happens.

1- The boot order and boot device is set in the BIOS of the computer.
Even if it's a SATA or RAID controller the BIOS *has* to be able to
see and read from the device to boot the computer. That is not
specific to Windows, it applies to any operating system.

I was wondering if the BIOS/hardware knew how to read the SATA or RAID
disk drive by itself. Which brings up the question, what exactly does
the SATA driver DO? Why does Windows need the SATA driver if the
hardware can read a SATA disk drive? You addressed this below, more
comments there.


[...]

4- The partition boot sector code locates the operating system loader
and loads it into memory and launches the execution of the operating
system loader. Up to this point the BIOS, Master Boot Code and
Partition Boot Sector Code have been responsible for the boot process.
This happens regardless of the file system on the disk and regardless
of the type of disk controller (IDE, SATA, RAID) and regardless of the
operating system to be loaded.

Interesting. I knew some of this but not in this detail.

5- As stated in step 4, the partition boot sector code executes the
operating system loader, in the case of Windows NT/2000/XP the
operating system loader is ntldr (short for nt loader). Ntldr
contains a mini file system driver that enables it to read the file
system on the disk and enables it to load the necessary files to load
Windows. Although it is universally accepted that ntldr is a part of
Windows, in a pure sense it really isn't. Ntldr is a DOS type program
that is responsible for *loading* Windows. While it is doing its job
Windows is not yet started, Windows will be started *by* ntldr.

I sort-of knew this too... but the NTLDR *file* itself is in the file
system; I thought it was not stored differently depending on whether the
disk is a FAT16, FAT32, NTFS 4, or NTFS 5 disk. The BIOS and hardware
are smart enough to read all of NTLDR in to memory, regardless of the
file system?

I have copied NTLDR from an NTFS disk to a floppy before, and booted
that floppy, so I presume NTLDR is just a regular file that's stored in
the file system.

6- Ntldr calls on NTDETECT.COM, another DOS type program,

At this point, all of NTLDR has been read from the disk into memory.
The hardware obviously knows how to read a SCSI disk without the help of
the SCSI driver.

to gather
information about the computer hardware. NTDETECT.COM will gather a
list and that list will be used to create the HKEY_LOCAL_MACHINE\
HARDWARE key. At this point Windows is not yet started, the boot
process is still being handled by ntldr.

*Here is the answer to your question* :

"At this time Ntldr scans all of the services in the Registry subkey
HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services for device
drivers with a Start value of 0x0, which indicates that they should be
loaded but not initialized. Device drivers with these values are
typically low-level hardware device drivers, such as hard disk device
drivers."

Right, but NTLDR has been read off of a (possibly) SCSI disk by the
hardware. Which makes me wonder why the SCSI driver is required for
Windows.

7- At the same time as events in step 6 were happening Ntldr began
loading NTOSKRNL.EXE but the boot process has not yet been passed on
to Windows. Ntldr will only pass the boot process after it has
finished loading drivers with an 0x0 value.

And that is why Windows knows how to use SCSI/SATA/RAID drivers, it
knows because ntldr loads boot device drivers (0x0) for Windows before
it actually loads Windows.

Yes, NTLDR loads boot device drivers off of a BOOT DEVICE. Somehow.

It still sounds like NTLDR loads itself off of the SCSI boot disk, in
the early part of the boot process.

You said that "Ntldr contains a mini file system driver". NTLDR is
stored in the file system, is it not?

It's still a little confusing. If the hardware can read a SCSI disk
without any help, then the SCSI driver doesn't do much useful work, does
it?

I'm really not trying to be obtuse. One of the steps seems like magic.


David

 

[Jim]

Thanks. A few comments interspersed below.

The question isn't hard to understand. Very quickly here is the
(condensed) low down on how it happens.

1- The boot order and boot device is set in the BIOS of the computer.
Even if it's a SATA or RAID controller the BIOS *has* to be able to
see and read from the device to boot the computer. That is not
specific to Windows, it applies to any operating system.

I was wondering if the BIOS/hardware knew how to read the SATA or RAID
disk drive by itself. Which brings up the question, what exactly does
the SATA driver DO? Why does Windows need the SATA driver if the
hardware can read a SATA disk drive? You addressed this below, more
comments there.


[...]

4- The partition boot sector code locates the operating system loader
and loads it into memory and launches the execution of the operating
system loader. Up to this point the BIOS, Master Boot Code and
Partition Boot Sector Code have been responsible for the boot process.
This happens regardless of the file system on the disk and regardless
of the type of disk controller (IDE, SATA, RAID) and regardless of the
operating system to be loaded.

Interesting. I knew some of this but not in this detail.

5- As stated in step 4, the partition boot sector code executes the
operating system loader, in the case of Windows NT/2000/XP the
operating system loader is ntldr (short for nt loader). Ntldr
contains a mini file system driver that enables it to read the file
system on the disk and enables it to load the necessary files to load
Windows. Although it is universally accepted that ntldr is a part of
Windows, in a pure sense it really isn't. Ntldr is a DOS type program
that is responsible for *loading* Windows. While it is doing its job
Windows is not yet started, Windows will be started *by* ntldr.

I sort-of knew this too... but the NTLDR *file* itself is in the file
system; I thought it was not stored differently depending on whether the
disk is a FAT16, FAT32, NTFS 4, or NTFS 5 disk. The BIOS and hardware
are smart enough to read all of NTLDR in to memory, regardless of the
file system?

I have copied NTLDR from an NTFS disk to a floppy before, and booted
that floppy, so I presume NTLDR is just a regular file that's stored in
the file system.

6- Ntldr calls on NTDETECT.COM, another DOS type program,

At this point, all of NTLDR has been read from the disk into memory.
The hardware obviously knows how to read a SCSI disk without the help of
the SCSI driver.

to gather
information about the computer hardware. NTDETECT.COM will gather a
list and that list will be used to create the HKEY_LOCAL_MACHINE\
HARDWARE key. At this point Windows is not yet started, the boot
process is still being handled by ntldr.

*Here is the answer to your question* :

"At this time Ntldr scans all of the services in the Registry subkey
HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services for device
drivers with a Start value of 0x0, which indicates that they should be
loaded but not initialized. Device drivers with these values are
typically low-level hardware device drivers, such as hard disk device
drivers."

Right, but NTLDR has been read off of a (possibly) SCSI disk by the
hardware. Which makes me wonder why the SCSI driver is required for
Windows.

7- At the same time as events in step 6 were happening Ntldr began
loading NTOSKRNL.EXE but the boot process has not yet been passed on
to Windows. Ntldr will only pass the boot process after it has
finished loading drivers with an 0x0 value.

And that is why Windows knows how to use SCSI/SATA/RAID drivers, it
knows because ntldr loads boot device drivers (0x0) for Windows before
it actually loads Windows.

Yes, NTLDR loads boot device drivers off of a BOOT DEVICE. Somehow.

It still sounds like NTLDR loads itself off of the SCSI boot disk, in
the early part of the boot process.

You said that "Ntldr contains a mini file system driver". NTLDR is
stored in the file system, is it not?

It's still a little confusing. If the hardware can read a SCSI disk
without any help, then the SCSI driver doesn't do much useful work, does
it?

I'm really not trying to be obtuse. One of the steps seems like magic.


David

The SCSI controller contains its own BIOS which supplements or overlays the
one on the motherboard.
This BIOS can definitely read a SCSI disk.
This process is also used in the IDE controllers that you can install in a
PCI slot.

The fine manual for the SCSI controller should describe the process in
greater detail.

The supplementation or overlaying occurs when power is applied.

Windows however does not seem to use any of the BIOS drivers hence it needs
a drivers stored on the system disk.

In the case of SATA devices directly connected to the motherboard, the
motherboard BIOS must have its own SATA drivers. However, you would still
need to supply drivers for Windows.

Jim

 

[DWalker]

It's still a little confusing. If the hardware can read a SCSI disk

The SCSI controller contains its own BIOS which supplements or
overlays the one on the motherboard.
This BIOS can definitely read a SCSI disk.
This process is also used in the IDE controllers that you can install
in a PCI slot.

The fine manual for the SCSI controller should describe the process in
greater detail.

The supplementation or overlaying occurs when power is applied.

Windows however does not seem to use any of the BIOS drivers hence it
needs a drivers stored on the system disk.

In the case of SATA devices directly connected to the motherboard, the
motherboard BIOS must have its own SATA drivers. However, you would
still need to supply drivers for Windows.

Jim

OK, that helps explain it.

Thanks to everyone.


David