Boot & System Volumes revisited

NTDEV
1

I'm trying to ensure that a destructive disk utility I'm doing doesn't whack
disks that the OS depends on. I've figured out how to make sure I don't
wipe a volume with a page file, and the volume containing %SystemRoot% is
easy, too. However, the volume containing the boot files is not, as far as
I've been able to gather. I've seen a some messages describing the
definitions of Windows Boot & System Volumes, and I've found a few things
which don't seem to fit the models described by others, so I'm hoping that
someone can fill in the blanks.

I've seen reference to the boot volume being the place where ntldr,
NTDETECT.COM, and boot.ini reside, and the system volume being
%SystemDrive%, or the volume containing %SystemRoot%. Those don't seem to
be consistent with the display in Disk Management.

I did a test, as follows: I took an XP system, on which everything was
installed on C:, which is the Primary Master ATA device, NTFS. The XP
installation had all current updates, including SP1. There was a FAT32 D:,
Primary Slave ATA device. The system also had a SCSI HBA with an
unformatted disk attached. If I looked at Disk Management, C: showed
"Healthy (System)".

I enabled INT13 on the SCSI HBA, but didn't change the BIOS boot order, so
the BIOS still orders the ATA drives ahead of the SCSI drive. Then I took
my handy-dandy MSDN DVD, put it into the DVD drive, and selected Install XP
Pro. I selected the unpartitioned SCSI disk space, installed XP, then
booted into the new installation, expecting to find that the SCSI drive had
become the system drive. I was quite surprised when I looked at Disk
Management. Now the old C: and D: are the same, including C: showing
(System). The SCSI drive is now F:, and it shows (Boot). The single page
file this installation is using is on F:, and there is no ntldr,
NTDETECT.COM, or boot.ini, in the root of F:. The ntldr & NTDETECT.COM in
C: are now the RTM versions, and of course, C:\boot.ini was changed to add
the path to the new installation.

Just out of curiosity, I moved the ntldr, NTDETECT.COM, and boot.ini to D:,
then booted from a floppy with the same files. Same display in Disk
Management. Then I disabled the disk where C: resides, and it went offline
just fine. F: still shows (Boot). I restarted, and D: now shows (System).
I removed the boot files from D:, and restarted again. D: still shows
(System). Here's where I am at a loss to explain how the "system" drive is
determined. For this particular "Windows Session", the "System" volume, if
that is where the boot files reside, is A:. More info, with C:\boot.ini
unavailable, System Properties complains that it can't find it when I click
the Startup and Recovery button, and then the default selector and the
timeout editor are disabled.

I have a theory about the "System" volume, that Windows is defining the
first volume (partition) of whatever comes up as "\Device\HardDisk0" as the
"System" volume. Can anyone confirm this?

With all of this info, it appears that the most reliable way to keep from
whacking the voume where the boot files reside is to simply search for them,
and mark any partitions on which they are found as off-limits. Anyone have
a better idea?

Thanks,

Phil

Philip D. Barila
Seagate Technology, LLC
(720) 684-1842
As if I need to say it: Not speaking for Seagate.

2

"Boot volume" is the volume on which %SystemRoot% resides.
"System volume" is the volume off which the OS boots (i.e. containing
NTLDR and the boot sector).
Yes, the terminology is a bit misleading, but unfortunately, that's the
way it is.

If you find MS documentation indicating contrary, please send the link
to me, I'll forward it to our
doc folks to fix.

Ravi

-----Original Message-----
From: Phil Barila [mailto:xxxxx@Seagate.com]
Sent: Thursday, January 09, 2003 10:49 AM
To: NT Developers Interest List
Subject: [ntdev] Boot & System Volumes revisited

I'm trying to ensure that a destructive disk utility I'm doing doesn't
whack disks that the OS depends on. I've figured out how to make sure I
don't wipe a volume with a page file, and the volume containing
%SystemRoot% is easy, too. However, the volume containing the boot
files is not, as far as I've been able to gather. I've seen a some
messages describing the definitions of Windows Boot & System Volumes,
and I've found a few things which don't seem to fit the models described
by others, so I'm hoping that someone can fill in the blanks.

I've seen reference to the boot volume being the place where ntldr,
NTDETECT.COM, and boot.ini reside, and the system volume being
%SystemDrive%, or the volume containing %SystemRoot%. Those don't seem
to be consistent with the display in Disk Management.

I did a test, as follows: I took an XP system, on which everything was
installed on C:, which is the Primary Master ATA device, NTFS. The XP
installation had all current updates, including SP1. There was a FAT32
D:, Primary Slave ATA device. The system also had a SCSI HBA with an
unformatted disk attached. If I looked at Disk Management, C: showed
"Healthy (System)".

I enabled INT13 on the SCSI HBA, but didn't change the BIOS boot order,
so the BIOS still orders the ATA drives ahead of the SCSI drive. Then I
took my handy-dandy MSDN DVD, put it into the DVD drive, and selected
Install XP Pro. I selected the unpartitioned SCSI disk space, installed
XP, then booted into the new installation, expecting to find that the
SCSI drive had become the system drive. I was quite surprised when I
looked at Disk Management. Now the old C: and D: are the same,
including C: showing (System). The SCSI drive is now F:, and it shows
(Boot). The single page file this installation is using is on F:, and
there is no ntldr, NTDETECT.COM, or boot.ini, in the root of F:. The
ntldr & NTDETECT.COM in
C: are now the RTM versions, and of course, C:\boot.ini was changed to
add the path to the new installation.

Just out of curiosity, I moved the ntldr, NTDETECT.COM, and boot.ini to
D:, then booted from a floppy with the same files. Same display in
Disk Management. Then I disabled the disk where C: resides, and it went
offline just fine. F: still shows (Boot). I restarted, and D: now
shows (System). I removed the boot files from D:, and restarted again.
D: still shows (System). Here's where I am at a loss to explain how the
"system" drive is determined. For this particular "Windows Session",
the "System" volume, if that is where the boot files reside, is A:.
More info, with C:\boot.ini unavailable, System Properties complains
that it can't find it when I click the Startup and Recovery button, and
then the default selector and the timeout editor are disabled.

I have a theory about the "System" volume, that Windows is defining the
first volume (partition) of whatever comes up as "\Device\HardDisk0" as
the "System" volume. Can anyone confirm this?

With all of this info, it appears that the most reliable way to keep
from whacking the voume where the boot files reside is to simply search
for them, and mark any partitions on which they are found as off-limits.
Anyone have a better idea?

Thanks,

Phil

Philip D. Barila
Seagate Technology, LLC
(720) 684-1842
As if I need to say it: Not speaking for Seagate.

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

3

This is an ignorant's question - I don't know much about Windows file
systems - but can't we know the boot volume by looking at the partition
table ? That's what I might do in a Linux system.

Alberto.

-----Original Message-----
From: Ravisankar Pudipeddi [mailto:xxxxx@windows.microsoft.com]
Sent: Thursday, January 09, 2003 2:49 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Boot & System Volumes revisited

"Boot volume" is the volume on which %SystemRoot% resides.
"System volume" is the volume off which the OS boots (i.e. containing
NTLDR and the boot sector).
Yes, the terminology is a bit misleading, but unfortunately, that's the
way it is.

If you find MS documentation indicating contrary, please send the link
to me, I'll forward it to our
doc folks to fix.

Ravi

-----Original Message-----
From: Phil Barila [mailto:xxxxx@Seagate.com]
Sent: Thursday, January 09, 2003 10:49 AM
To: NT Developers Interest List
Subject: [ntdev] Boot & System Volumes revisited

I'm trying to ensure that a destructive disk utility I'm doing doesn't
whack disks that the OS depends on. I've figured out how to make sure I
don't wipe a volume with a page file, and the volume containing
%SystemRoot% is easy, too. However, the volume containing the boot
files is not, as far as I've been able to gather. I've seen a some
messages describing the definitions of Windows Boot & System Volumes,
and I've found a few things which don't seem to fit the models described
by others, so I'm hoping that someone can fill in the blanks.

I've seen reference to the boot volume being the place where ntldr,
NTDETECT.COM, and boot.ini reside, and the system volume being
%SystemDrive%, or the volume containing %SystemRoot%. Those don't seem
to be consistent with the display in Disk Management.

I did a test, as follows: I took an XP system, on which everything was
installed on C:, which is the Primary Master ATA device, NTFS. The XP
installation had all current updates, including SP1. There was a FAT32
D:, Primary Slave ATA device. The system also had a SCSI HBA with an
unformatted disk attached. If I looked at Disk Management, C: showed
"Healthy (System)".

I enabled INT13 on the SCSI HBA, but didn't change the BIOS boot order,
so the BIOS still orders the ATA drives ahead of the SCSI drive. Then I
took my handy-dandy MSDN DVD, put it into the DVD drive, and selected
Install XP Pro. I selected the unpartitioned SCSI disk space, installed
XP, then booted into the new installation, expecting to find that the
SCSI drive had become the system drive. I was quite surprised when I
looked at Disk Management. Now the old C: and D: are the same,
including C: showing (System). The SCSI drive is now F:, and it shows
(Boot). The single page file this installation is using is on F:, and
there is no ntldr, NTDETECT.COM, or boot.ini, in the root of F:. The
ntldr & NTDETECT.COM in
C: are now the RTM versions, and of course, C:\boot.ini was changed to
add the path to the new installation.

Just out of curiosity, I moved the ntldr, NTDETECT.COM, and boot.ini to
D:, then booted from a floppy with the same files. Same display in
Disk Management. Then I disabled the disk where C: resides, and it went
offline just fine. F: still shows (Boot). I restarted, and D: now
shows (System). I removed the boot files from D:, and restarted again.
D: still shows (System). Here's where I am at a loss to explain how the
"system" drive is determined. For this particular "Windows Session",
the "System" volume, if that is where the boot files reside, is A:.
More info, with C:\boot.ini unavailable, System Properties complains
that it can't find it when I click the Startup and Recovery button, and
then the default selector and the timeout editor are disabled.

I have a theory about the "System" volume, that Windows is defining the
first volume (partition) of whatever comes up as "\Device\HardDisk0" as
the "System" volume. Can anyone confirm this?

With all of this info, it appears that the most reliable way to keep
from whacking the voume where the boot files reside is to simply search
for them, and mark any partitions on which they are found as off-limits.
Anyone have a better idea?

Thanks,

Phil

Philip D. Barila
Seagate Technology, LLC
(720) 684-1842
As if I need to say it: Not speaking for Seagate.

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.

4

(using ravi's terminology here)

A drive with multiple partitions could have \Windows directories on
multiple of those partitions. My test machines are all setup with two
partitions, each of which has an installation. The system partition can
be found in this case by checking the active flag in the partition
information, but the boot volume cannot be derived from the partition
table alone.

In a system with multiple drives each of those drives could have a
partition set as active. In that case even examining the partition
tables doesn't tell you which is the system partition.

-p

-----Original Message-----
From: Moreira, Alberto [mailto:xxxxx@compuware.com]
Sent: Thursday, January 09, 2003 11:55 AM
To: NT Developers Interest List

This is an ignorant's question - I don't know much about Windows file
systems - but can't we know the boot volume by looking at the partition
table ? That's what I might do in a Linux system.

Alberto.

-----Original Message-----
From: Ravisankar Pudipeddi [mailto:xxxxx@windows.microsoft.com]
Sent: Thursday, January 09, 2003 2:49 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Boot & System Volumes revisited

"Boot volume" is the volume on which %SystemRoot% resides.
"System volume" is the volume off which the OS boots (i.e. containing
NTLDR and the boot sector).
Yes, the terminology is a bit misleading, but unfortunately, that's the
way it is.

If you find MS documentation indicating contrary, please send the link
to me, I'll forward it to our doc folks to fix.

Ravi

-----Original Message-----
From: Phil Barila [mailto:xxxxx@Seagate.com]
Sent: Thursday, January 09, 2003 10:49 AM
To: NT Developers Interest List
Subject: [ntdev] Boot & System Volumes revisited

I'm trying to ensure that a destructive disk utility I'm doing doesn't
whack disks that the OS depends on. I've figured out how to make sure I
don't wipe a volume with a page file, and the volume containing
%SystemRoot% is easy, too. However, the volume containing the boot
files is not, as far as I've been able to gather. I've seen a some
messages describing the definitions of Windows Boot & System Volumes,
and I've found a few things which don't seem to fit the models described
by others, so I'm hoping that someone can fill in the blanks.

I've seen reference to the boot volume being the place where ntldr,
NTDETECT.COM, and boot.ini reside, and the system volume being
%SystemDrive%, or the volume containing %SystemRoot%. Those don't seem
to be consistent with the display in Disk Management.

I did a test, as follows: I took an XP system, on which everything was
installed on C:, which is the Primary Master ATA device, NTFS. The XP
installation had all current updates, including SP1. There was a FAT32
D:, Primary Slave ATA device. The system also had a SCSI HBA with an
unformatted disk attached. If I looked at Disk Management, C: showed
"Healthy (System)".

I enabled INT13 on the SCSI HBA, but didn't change the BIOS boot order,
so the BIOS still orders the ATA drives ahead of the SCSI drive. Then I
took my handy-dandy MSDN DVD, put it into the DVD drive, and selected
Install XP Pro. I selected the unpartitioned SCSI disk space, installed
XP, then booted into the new installation, expecting to find that the
SCSI drive had become the system drive. I was quite surprised when I
looked at Disk Management. Now the old C: and D: are the same,
including C: showing (System). The SCSI drive is now F:, and it shows
(Boot). The single page file this installation is using is on F:, and
there is no ntldr, NTDETECT.COM, or boot.ini, in the root of F:. The
ntldr & NTDETECT.COM in
C: are now the RTM versions, and of course, C:\boot.ini was changed to
add the path to the new installation.

Just out of curiosity, I moved the ntldr, NTDETECT.COM, and boot.ini to
D:, then booted from a floppy with the same files. Same display in
Disk Management. Then I disabled the disk where C: resides, and it went
offline just fine. F: still shows (Boot). I restarted, and D: now
shows (System). I removed the boot files from D:, and restarted again.
D: still shows (System). Here's where I am at a loss to explain how the
"system" drive is determined. For this particular "Windows Session",
the "System" volume, if that is where the boot files reside, is A:.
More info, with C:\boot.ini unavailable, System Properties complains
that it can't find it when I click the Startup and Recovery button, and
then the default selector and the timeout editor are disabled.

I have a theory about the "System" volume, that Windows is defining the
first volume (partition) of whatever comes up as "\Device\HardDisk0" as
the "System" volume. Can anyone confirm this?

With all of this info, it appears that the most reliable way to keep
from whacking the voume where the boot files reside is to simply search
for them, and mark any partitions on which they are found as off-limits.
Anyone have a better idea?

Thanks,

Phil

Philip D. Barila
Seagate Technology, LLC
(720) 684-1842
As if I need to say it: Not speaking for Seagate.

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

The contents of this e-mail are intended for the named addressee only.
It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or
disclose
it to anyone else. If you received it in error please notify us
immediately
and then destroy it.

You are currently subscribed to ntdev as: xxxxx@microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

5

But in that case, how does for example LILO know where to boot from, when we
choose the Windows partition instead of the Linux one ?

-----Original Message-----
From: Peter Wieland [mailto:xxxxx@windows.microsoft.com]
Sent: Thursday, January 09, 2003 3:12 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Boot & System Volumes revisited

(using ravi's terminology here)

A drive with multiple partitions could have \Windows directories on
multiple of those partitions. My test machines are all setup with two
partitions, each of which has an installation. The system partition can
be found in this case by checking the active flag in the partition
information, but the boot volume cannot be derived from the partition
table alone.

In a system with multiple drives each of those drives could have a
partition set as active. In that case even examining the partition
tables doesn't tell you which is the system partition.

-p

-----Original Message-----
From: Moreira, Alberto [mailto:xxxxx@compuware.com]
Sent: Thursday, January 09, 2003 11:55 AM
To: NT Developers Interest List

This is an ignorant's question - I don't know much about Windows file
systems - but can't we know the boot volume by looking at the partition
table ? That's what I might do in a Linux system.

Alberto.

-----Original Message-----
From: Ravisankar Pudipeddi [mailto:xxxxx@windows.microsoft.com]
Sent: Thursday, January 09, 2003 2:49 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Boot & System Volumes revisited

"Boot volume" is the volume on which %SystemRoot% resides.
"System volume" is the volume off which the OS boots (i.e. containing
NTLDR and the boot sector).
Yes, the terminology is a bit misleading, but unfortunately, that's the
way it is.

If you find MS documentation indicating contrary, please send the link
to me, I'll forward it to our doc folks to fix.

Ravi

-----Original Message-----
From: Phil Barila [mailto:xxxxx@Seagate.com]
Sent: Thursday, January 09, 2003 10:49 AM
To: NT Developers Interest List
Subject: [ntdev] Boot & System Volumes revisited

I'm trying to ensure that a destructive disk utility I'm doing doesn't
whack disks that the OS depends on. I've figured out how to make sure I
don't wipe a volume with a page file, and the volume containing
%SystemRoot% is easy, too. However, the volume containing the boot
files is not, as far as I've been able to gather. I've seen a some
messages describing the definitions of Windows Boot & System Volumes,
and I've found a few things which don't seem to fit the models described
by others, so I'm hoping that someone can fill in the blanks.

I've seen reference to the boot volume being the place where ntldr,
NTDETECT.COM, and boot.ini reside, and the system volume being
%SystemDrive%, or the volume containing %SystemRoot%. Those don't seem
to be consistent with the display in Disk Management.

I did a test, as follows: I took an XP system, on which everything was
installed on C:, which is the Primary Master ATA device, NTFS. The XP
installation had all current updates, including SP1. There was a FAT32
D:, Primary Slave ATA device. The system also had a SCSI HBA with an
unformatted disk attached. If I looked at Disk Management, C: showed
"Healthy (System)".

I enabled INT13 on the SCSI HBA, but didn't change the BIOS boot order,
so the BIOS still orders the ATA drives ahead of the SCSI drive. Then I
took my handy-dandy MSDN DVD, put it into the DVD drive, and selected
Install XP Pro. I selected the unpartitioned SCSI disk space, installed
XP, then booted into the new installation, expecting to find that the
SCSI drive had become the system drive. I was quite surprised when I
looked at Disk Management. Now the old C: and D: are the same,
including C: showing (System). The SCSI drive is now F:, and it shows
(Boot). The single page file this installation is using is on F:, and
there is no ntldr, NTDETECT.COM, or boot.ini, in the root of F:. The
ntldr & NTDETECT.COM in
C: are now the RTM versions, and of course, C:\boot.ini was changed to
add the path to the new installation.

Just out of curiosity, I moved the ntldr, NTDETECT.COM, and boot.ini to
D:, then booted from a floppy with the same files. Same display in
Disk Management. Then I disabled the disk where C: resides, and it went
offline just fine. F: still shows (Boot). I restarted, and D: now
shows (System). I removed the boot files from D:, and restarted again.
D: still shows (System). Here's where I am at a loss to explain how the
"system" drive is determined. For this particular "Windows Session",
the "System" volume, if that is where the boot files reside, is A:.
More info, with C:\boot.ini unavailable, System Properties complains
that it can't find it when I click the Startup and Recovery button, and
then the default selector and the timeout editor are disabled.

I have a theory about the "System" volume, that Windows is defining the
first volume (partition) of whatever comes up as "\Device\HardDisk0" as
the "System" volume. Can anyone confirm this?

With all of this info, it appears that the most reliable way to keep
from whacking the voume where the boot files reside is to simply search
for them, and mark any partitions on which they are found as off-limits.
Anyone have a better idea?

Thanks,

Phil

Philip D. Barila
Seagate Technology, LLC
(720) 684-1842
As if I need to say it: Not speaking for Seagate.

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

The contents of this e-mail are intended for the named addressee only.
It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or
disclose
it to anyone else. If you received it in error please notify us
immediately
and then destroy it.

You are currently subscribed to ntdev as: xxxxx@microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.

6

Not sure since I've never used LILO, but I'd guess it does something
simple like boot from the active partition on BIOS disk 0x80 (the first
disk reported by the BIOS).

This is what the BIOS would generally do without LILO installed.

-p

-----Original Message-----
From: Moreira, Alberto [mailto:xxxxx@compuware.com]
Sent: Thursday, January 09, 2003 12:22 PM
To: NT Developers Interest List

But in that case, how does for example LILO know where to boot from,
when we choose the Windows partition instead of the Linux one ?

-----Original Message-----
From: Peter Wieland [mailto:xxxxx@windows.microsoft.com]
Sent: Thursday, January 09, 2003 3:12 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Boot & System Volumes revisited

(using ravi's terminology here)

A drive with multiple partitions could have \Windows directories on
multiple of those partitions. My test machines are all setup with two
partitions, each of which has an installation. The system partition can
be found in this case by checking the active flag in the partition
information, but the boot volume cannot be derived from the partition
table alone.

In a system with multiple drives each of those drives could have a
partition set as active. In that case even examining the partition
tables doesn't tell you which is the system partition.

-p

-----Original Message-----
From: Moreira, Alberto [mailto:xxxxx@compuware.com]
Sent: Thursday, January 09, 2003 11:55 AM
To: NT Developers Interest List

This is an ignorant's question - I don't know much about Windows file
systems - but can't we know the boot volume by looking at the partition
table ? That's what I might do in a Linux system.

Alberto.

-----Original Message-----
From: Ravisankar Pudipeddi [mailto:xxxxx@windows.microsoft.com]
Sent: Thursday, January 09, 2003 2:49 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Boot & System Volumes revisited

"Boot volume" is the volume on which %SystemRoot% resides.
"System volume" is the volume off which the OS boots (i.e. containing
NTLDR and the boot sector).
Yes, the terminology is a bit misleading, but unfortunately, that's the
way it is.

If you find MS documentation indicating contrary, please send the link
to me, I'll forward it to our doc folks to fix.

Ravi

-----Original Message-----
From: Phil Barila [mailto:xxxxx@Seagate.com]
Sent: Thursday, January 09, 2003 10:49 AM
To: NT Developers Interest List
Subject: [ntdev] Boot & System Volumes revisited

I'm trying to ensure that a destructive disk utility I'm doing doesn't
whack disks that the OS depends on. I've figured out how to make sure I
don't wipe a volume with a page file, and the volume containing
%SystemRoot% is easy, too. However, the volume containing the boot
files is not, as far as I've been able to gather. I've seen a some
messages describing the definitions of Windows Boot & System Volumes,
and I've found a few things which don't seem to fit the models described
by others, so I'm hoping that someone can fill in the blanks.

I've seen reference to the boot volume being the place where ntldr,
NTDETECT.COM, and boot.ini reside, and the system volume being
%SystemDrive%, or the volume containing %SystemRoot%. Those don't seem
to be consistent with the display in Disk Management.

I did a test, as follows: I took an XP system, on which everything was
installed on C:, which is the Primary Master ATA device, NTFS. The XP
installation had all current updates, including SP1. There was a FAT32
D:, Primary Slave ATA device. The system also had a SCSI HBA with an
unformatted disk attached. If I looked at Disk Management, C: showed
"Healthy (System)".

I enabled INT13 on the SCSI HBA, but didn't change the BIOS boot order,
so the BIOS still orders the ATA drives ahead of the SCSI drive. Then I
took my handy-dandy MSDN DVD, put it into the DVD drive, and selected
Install XP Pro. I selected the unpartitioned SCSI disk space, installed
XP, then booted into the new installation, expecting to find that the
SCSI drive had become the system drive. I was quite surprised when I
looked at Disk Management. Now the old C: and D: are the same,
including C: showing (System). The SCSI drive is now F:, and it shows
(Boot). The single page file this installation is using is on F:, and
there is no ntldr, NTDETECT.COM, or boot.ini, in the root of F:. The
ntldr & NTDETECT.COM in
C: are now the RTM versions, and of course, C:\boot.ini was changed to
add the path to the new installation.

Just out of curiosity, I moved the ntldr, NTDETECT.COM, and boot.ini to
D:, then booted from a floppy with the same files. Same display in
Disk Management. Then I disabled the disk where C: resides, and it went
offline just fine. F: still shows (Boot). I restarted, and D: now
shows (System). I removed the boot files from D:, and restarted again.
D: still shows (System). Here's where I am at a loss to explain how the
"system" drive is determined. For this particular "Windows Session",
the "System" volume, if that is where the boot files reside, is A:.
More info, with C:\boot.ini unavailable, System Properties complains
that it can't find it when I click the Startup and Recovery button, and
then the default selector and the timeout editor are disabled.

I have a theory about the "System" volume, that Windows is defining the
first volume (partition) of whatever comes up as "\Device\HardDisk0" as
the "System" volume. Can anyone confirm this?

With all of this info, it appears that the most reliable way to keep
from whacking the voume where the boot files reside is to simply search
for them, and mark any partitions on which they are found as off-limits.
Anyone have a better idea?

Thanks,

Phil

Philip D. Barila
Seagate Technology, LLC
(720) 684-1842
As if I need to say it: Not speaking for Seagate.

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

The contents of this e-mail are intended for the named addressee only.
It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or
disclose it to anyone else. If you received it in error please notify us
immediately and then destroy it.

You are currently subscribed to ntdev as: xxxxx@microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

The contents of this e-mail are intended for the named addressee only.
It contains information that may be confidential. Unless you are the
named addressee or an authorized designee, you may not copy or use it,
or disclose it to anyone else. If you received it in error please notify
us immediately and then destroy it.

You are currently subscribed to ntdev as: xxxxx@microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

7

xxxxx@sneakemail.com said:

But in that case, how does for example LILO know where to boot from,
when we choose the Windows partition instead of the Linux one ?

I'm no expert (read the LILO documentation:-) but:

The lilo.conf file contains the information about what systems
are in what partitions. Partitions in turn have boot blocks
that get loaded. The "lilo" command under Linux stashes the
contents of the config file in magical places where the lilo
bootstrap loader can easily find them.

Lilo itself gets written in the master boot record of the disk,
so that the BIOS can find and load it.

After BIOS loads and runs LILO, and you select Windows 2000,
it reads a boot block from the configured partition, which is
the ntloader, and from there it continues as normal.

Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
steve at picturel.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."

8

Of course. Lilo.conf tells it where to boot from.

Alberto.

-----Original Message-----
From: Stephen Williams [mailto:xxxxx@sneakemail.com]
Sent: Thursday, January 09, 2003 4:09 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Boot & System Volumes revisited

xxxxx@sneakemail.com said:

But in that case, how does for example LILO know where to boot from,
when we choose the Windows partition instead of the Linux one ?

I'm no expert (read the LILO documentation:-) but:

The lilo.conf file contains the information about what systems
are in what partitions. Partitions in turn have boot blocks
that get loaded. The "lilo" command under Linux stashes the
contents of the config file in magical places where the lilo
bootstrap loader can easily find them.

Lilo itself gets written in the master boot record of the disk,
so that the BIOS can find and load it.

After BIOS loads and runs LILO, and you select Windows 2000,
it reads a boot block from the configured partition, which is
the ntloader, and from there it continues as normal.

Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
steve at picturel.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."

You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.

9

Microsoft has, as one reply indicated, a very confusing description/name for
this stuff. I think you know a lot of this, but I will try to explain it as
I understand it.

  1. The BIOS will look at hard drive 80h for the first sector to contain a
    signature of 0x55AA.
  2. It then load that sector into memory and the code within it looks for an
    active partition.
  3. That active partition’s boot record is loaded and executed.

Some BIOS’s permit drives other than 80h to be the boot drive either by just
doing it with a 81h or by swapping the drives around.

  1. If Windows XP, 2K, or NT the partition boot record loads NTLDR. That
    NTLDR or NTDETECT.COM or both are unique as to the type of hard drive
    controller running the boot drive. I understand that Microsoft has a IDE &
    SCSI version of the file(s).
  2. NTLDR parses the boot.ini file and uses the ARC names to find what and
    where to load.

I have written code that was loaded by the MBR, sector zero, and then went
out and found code to execute before even starting the OS. The was a drive
encryption product for DOS, but it could require that a password be entered
before the boot could continue. The partitions or parts of the partitions
were encrypted and had to be decrypted at the INT 13h level.

----- Original Message -----
From: “Phil Barila”
Newsgroups: ntdev
To: “NT Developers Interest List”
Sent: Thursday, January 09, 2003 1:49 PM
Subject: [ntdev] Boot & System Volumes revisited

> I’m trying to ensure that a destructive disk utility I’m doing doesn’t
whack
> disks that the OS depends on. I’ve figured out how to make sure I don’t
> wipe a volume with a page file, and the volume containing %SystemRoot% is
> easy, too. However, the volume containing the boot files is not, as far
as
> I’ve been able to gather. I’ve seen a some messages describing the
> definitions of Windows Boot & System Volumes, and I’ve found a few things
> which don’t seem to fit the models described by others, so I’m hoping that
> someone can fill in the blanks.
>
> I’ve seen reference to the boot volume being the place where ntldr,
> NTDETECT.COM, and boot.ini reside, and the system volume being
> %SystemDrive%, or the volume containing %SystemRoot%. Those don’t seem to
> be consistent with the display in Disk Management.
>
> I did a test, as follows: I took an XP system, on which everything was
> installed on C:, which is the Primary Master ATA device, NTFS. The XP
> installation had all current updates, including SP1. There was a FAT32
D:,
> Primary Slave ATA device. The system also had a SCSI HBA with an
> unformatted disk attached. If I looked at Disk Management, C: showed
> “Healthy (System)”.
>
> I enabled INT13 on the SCSI HBA, but didn’t change the BIOS boot order, so
> the BIOS still orders the ATA drives ahead of the SCSI drive. Then I took
> my handy-dandy MSDN DVD, put it into the DVD drive, and selected Install
XP
> Pro. I selected the unpartitioned SCSI disk space, installed XP, then
> booted into the new installation, expecting to find that the SCSI drive
had
> become the system drive. I was quite surprised when I looked at Disk
> Management. Now the old C: and D: are the same, including C: showing
> (System). The SCSI drive is now F:, and it shows (Boot). The single page
> file this installation is using is on F:, and there is no ntldr,
> NTDETECT.COM, or boot.ini, in the root of F:. The ntldr & NTDETECT.COM in
> C: are now the RTM versions, and of course, C:\boot.ini was changed to add
> the path to the new installation.
>
> Just out of curiosity, I moved the ntldr, NTDETECT.COM, and boot.ini to
D:,
> then booted from a floppy with the same files. Same display in Disk
> Management. Then I disabled the disk where C: resides, and it went
offline
> just fine. F: still shows (Boot). I restarted, and D: now shows
(System).
> I removed the boot files from D:, and restarted again. D: still shows
> (System). Here’s where I am at a loss to explain how the “system” drive
is
> determined. For this particular “Windows Session”, the “System” volume,
if
> that is where the boot files reside, is A:. More info, with C:\boot.ini
> unavailable, System Properties complains that it can’t find it when I
click
> the Startup and Recovery button, and then the default selector and the
> timeout editor are disabled.
>
> I have a theory about the “System” volume, that Windows is defining the
> first volume (partition) of whatever comes up as “\Device\HardDisk0” as
the
> “System” volume. Can anyone confirm this?
>
> With all of this info, it appears that the most reliable way to keep from
> whacking the voume where the boot files reside is to simply search for
them,
> and mark any partitions on which they are found as off-limits. Anyone
have
> a better idea?
>
> Thanks,
>
> Phil
> –
> Philip D. Barila
> Seagate Technology, LLC
> (720) 684-1842
> As if I need to say it: Not speaking for Seagate.
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@yoshimuni.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com

10

Not any MS documentation, just stuff here and on some newsgroups. It seems
that more than one person has tripped over the non-intuitive nature of this
terminology. "Inside Windows 2000, 3rd Ed." has it right.

However, as I detailed below, the system doesn't really identify the "System
Volume" as the place it booted from, because if it did, there would be some
indication of that in the event that you put ntldr, NTDETECT.COM, and
boot.ini on a floppy, and boot from that.

So really, how does Disk Management decide which volume it will label as
"(System)"? It's certainly not due to the presence of those three files.

(In the flattest Ben Stein I can muster)
"Anybody...? Bueller...?"

Phil

Philip D. Barila
Seagate Technology, LLC
(720) 684-1842
As if I need to say it: Not speaking for Seagate.

"Ravisankar Pudipeddi" wrote in message
news:xxxxx@ntdev...

"Boot volume" is the volume on which %SystemRoot% resides.
"System volume" is the volume off which the OS boots (i.e. containing
NTLDR and the boot sector).
Yes, the terminology is a bit misleading, but unfortunately, that's the
way it is.

If you find MS documentation indicating contrary, please send the link
to me, I'll forward it to our
doc folks to fix.

Ravi

-----Original Message-----
From: Phil Barila [mailto:xxxxx@Seagate.com]
Sent: Thursday, January 09, 2003 10:49 AM
To: NT Developers Interest List
Subject: [ntdev] Boot & System Volumes revisited

I'm trying to ensure that a destructive disk utility I'm doing doesn't
whack disks that the OS depends on. I've figured out how to make sure I
don't wipe a volume with a page file, and the volume containing
%SystemRoot% is easy, too. However, the volume containing the boot
files is not, as far as I've been able to gather. I've seen a some
messages describing the definitions of Windows Boot & System Volumes,
and I've found a few things which don't seem to fit the models described
by others, so I'm hoping that someone can fill in the blanks.

I've seen reference to the boot volume being the place where ntldr,
NTDETECT.COM, and boot.ini reside, and the system volume being
%SystemDrive%, or the volume containing %SystemRoot%. Those don't seem
to be consistent with the display in Disk Management.

I did a test, as follows: I took an XP system, on which everything was
installed on C:, which is the Primary Master ATA device, NTFS. The XP
installation had all current updates, including SP1. There was a FAT32
D:, Primary Slave ATA device. The system also had a SCSI HBA with an
unformatted disk attached. If I looked at Disk Management, C: showed
"Healthy (System)".

I enabled INT13 on the SCSI HBA, but didn't change the BIOS boot order,
so the BIOS still orders the ATA drives ahead of the SCSI drive. Then I
took my handy-dandy MSDN DVD, put it into the DVD drive, and selected
Install XP Pro. I selected the unpartitioned SCSI disk space, installed
XP, then booted into the new installation, expecting to find that the
SCSI drive had become the system drive. I was quite surprised when I
looked at Disk Management. Now the old C: and D: are the same,
including C: showing (System). The SCSI drive is now F:, and it shows
(Boot). The single page file this installation is using is on F:, and
there is no ntldr, NTDETECT.COM, or boot.ini, in the root of F:. The
ntldr & NTDETECT.COM in
C: are now the RTM versions, and of course, C:\boot.ini was changed to
add the path to the new installation.

Just out of curiosity, I moved the ntldr, NTDETECT.COM, and boot.ini to
D:, then booted from a floppy with the same files. Same display in
Disk Management. Then I disabled the disk where C: resides, and it went
offline just fine. F: still shows (Boot). I restarted, and D: now
shows (System). I removed the boot files from D:, and restarted again.
D: still shows (System). Here's where I am at a loss to explain how the
"system" drive is determined. For this particular "Windows Session",
the "System" volume, if that is where the boot files reside, is A:.
More info, with C:\boot.ini unavailable, System Properties complains
that it can't find it when I click the Startup and Recovery button, and
then the default selector and the timeout editor are disabled.

I have a theory about the "System" volume, that Windows is defining the
first volume (partition) of whatever comes up as "\Device\HardDisk0" as
the "System" volume. Can anyone confirm this?

With all of this info, it appears that the most reliable way to keep
from whacking the voume where the boot files reside is to simply search
for them, and mark any partitions on which they are found as off-limits.
Anyone have a better idea?

Thanks,

Phil
--
Philip D. Barila
Seagate Technology, LLC
(720) 684-1842
As if I need to say it: Not speaking for Seagate.

---
You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

11

“David J. Craig” wrote in message
news:xxxxx@ntdev…

[snip]

> 4. If Windows XP, 2K, or NT the partition boot record loads NTLDR. That
> NTLDR or NTDETECT.COM or both are unique as to the type of hard drive
> controller running the boot drive. I understand that Microsoft has a IDE
&
> SCSI version of the file(s).

[snip]

More like INT13 and non INT13. If the SCSI adapter has an INT13 BIOS, such
as the Adaptec I’m using, it’s the same thing. If there is a different boot
file, I would guess it would be the one that uses ntbootdd.sys. Since I’ve
never installed on an HBA that needed one, I’m only guessing.

Phil
–
Philip D. Barila
Seagate Technology, LLC
(720) 684-1842
As if I need to say it: Not speaking for Seagate.

12

> -----Original Message-----

From: Moreira, Alberto [mailto:xxxxx@compuware.com]
Sent: Thursday, January 09, 2003 12:22 PM

But in that case, how does for example LILO know where to
boot from, when we
choose the Windows partition instead of the Linux one ?

Lilo has a configuration file, lilo.conf, generally found in the /etc
directory of your basic linux installation.

Lilo.conf defines for lilo the drive/partition for all available boot
partitions (…that you want lilo to know about).

Harmony,

–Christine

13

Hello,

You got that right!

You have just reminded me about “Inside Win2k”, 3rd edition I think.
There is a very nice… ok, good explanation of this. If I recall
corectly it’s related to the MBR and the EBR. The second one should be
more important in case of NT systems. Also, those tree little files…
are not just copied on the disk. At least one(ntldr) has to begin on a
specific sector.

Why am I bothering with this message?!

Thank you,
Hardwired

Phil Barila wrote:

Not any MS documentation, just stuff here and on some newsgroups. It seems
that more than one person has tripped over the non-intuitive nature of this
terminology. “Inside Windows 2000, 3rd Ed.” has it right.

However, as I detailed below, the system doesn’t really identify the “System
Volume” as the place it booted from, because if it did, there would be some
indication of that in the event that you put ntldr, NTDETECT.COM, and
boot.ini on a floppy, and boot from that.

So really, how does Disk Management decide which volume it will label as
“(System)”? It’s certainly not due to the presence of those three files.

(In the flattest Ben Stein I can muster)
“Anybody…? Bueller…?”

Phil

Philip D. Barila
Seagate Technology, LLC
(720) 684-1842
As if I need to say it: Not speaking for Seagate.

“Ravisankar Pudipeddi” wrote in message
>news:xxxxx@ntdev…
>
>“Boot volume” is the volume on which %SystemRoot% resides.
>“System volume” is the volume off which the OS boots (i.e. containing
>NTLDR and the boot sector).
>Yes, the terminology is a bit misleading, but unfortunately, that’s the
>way it is.
>
>If you find MS documentation indicating contrary, please send the link
>to me, I’ll forward it to our
>doc folks to fix.
>
>Ravi
>
>
>-----Original Message-----
>From: Phil Barila [mailto:xxxxx@Seagate.com]
>Sent: Thursday, January 09, 2003 10:49 AM
>To: NT Developers Interest List
>Subject: [ntdev] Boot & System Volumes revisited
>
>
>I’m trying to ensure that a destructive disk utility I’m doing doesn’t
>whack disks that the OS depends on. I’ve figured out how to make sure I
>don’t wipe a volume with a page file, and the volume containing
>%SystemRoot% is easy, too. However, the volume containing the boot
>files is not, as far as I’ve been able to gather. I’ve seen a some
>messages describing the definitions of Windows Boot & System Volumes,
>and I’ve found a few things which don’t seem to fit the models described
>by others, so I’m hoping that someone can fill in the blanks.
>
>I’ve seen reference to the boot volume being the place where ntldr,
>NTDETECT.COM, and boot.ini reside, and the system volume being
>%SystemDrive%, or the volume containing %SystemRoot%. Those don’t seem
>to be consistent with the display in Disk Management.
>
>I did a test, as follows: I took an XP system, on which everything was
>installed on C:, which is the Primary Master ATA device, NTFS. The XP
>installation had all current updates, including SP1. There was a FAT32
>D:, Primary Slave ATA device. The system also had a SCSI HBA with an
>unformatted disk attached. If I looked at Disk Management, C: showed
>“Healthy (System)”.
>
>I enabled INT13 on the SCSI HBA, but didn’t change the BIOS boot order,
>so the BIOS still orders the ATA drives ahead of the SCSI drive. Then I
>took my handy-dandy MSDN DVD, put it into the DVD drive, and selected
>Install XP Pro. I selected the unpartitioned SCSI disk space, installed
>XP, then booted into the new installation, expecting to find that the
>SCSI drive had become the system drive. I was quite surprised when I
>looked at Disk Management. Now the old C: and D: are the same,
>including C: showing (System). The SCSI drive is now F:, and it shows
>(Boot). The single page file this installation is using is on F:, and
>there is no ntldr, NTDETECT.COM, or boot.ini, in the root of F:. The
>ntldr & NTDETECT.COM in
>C: are now the RTM versions, and of course, C:\boot.ini was changed to
>add the path to the new installation.
>
>Just out of curiosity, I moved the ntldr, NTDETECT.COM, and boot.ini to
>D:, then booted from a floppy with the same files. Same display in
>Disk Management. Then I disabled the disk where C: resides, and it went
>offline just fine. F: still shows (Boot). I restarted, and D: now
>shows (System). I removed the boot files from D:, and restarted again.
>D: still shows (System). Here’s where I am at a loss to explain how the
>“system” drive is determined. For this particular “Windows Session”,
>the “System” volume, if that is where the boot files reside, is A:.
>More info, with C:\boot.ini unavailable, System Properties complains
>that it can’t find it when I click the Startup and Recovery button, and
>then the default selector and the timeout editor are disabled.
>
>I have a theory about the “System” volume, that Windows is defining the
>first volume (partition) of whatever comes up as “\Device\HardDisk0” as
>the “System” volume. Can anyone confirm this?
>
>With all of this info, it appears that the most reliable way to keep
>from whacking the voume where the boot files reside is to simply search
>for them, and mark any partitions on which they are found as off-limits.
>Anyone have a better idea?
>
>Thanks,
>
>Phil
>–
>Philip D. Barila
>Seagate Technology, LLC
>(720) 684-1842
>As if I need to say it: Not speaking for Seagate.
>
>
>
>—
>You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
>To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
>
>
>—
>You are currently subscribed to ntdev as: xxxxx@rdslink.ro
>To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>

14

“Hardwired” wrote in message news:xxxxx@ntdev…

[snip]

> Also, those tree little files…
> are not just copied on the disk. At least one(ntldr) has to begin on a
> specific sector.

Umm, no, it doesn’t. I believe it used to, but at least in XP, it just
needs to be present in the root. You can verify this by copying those three
files to a floppy formatted by XP, then booting from that floppy. No matter
the order you copy them, it always boots OK on my test system. It appears
to be the same story if you remove those files from the boot partition, then
copy them back.

Phil
–
Philip D. Barila
Seagate Technology, LLC
(720) 684-1842
As if I need to say it: Not speaking for Seagate.
E-mail address is pointed at a domain squatter. Use reply-to instead.

15

IIRC windows save volume name as well as driver letter somewhere on the boot
disk and they are retrived by Ntdetect or Ntloader. That is why different
boots pick up the same driver letter and volume name on the same PC.

MBR contains code that leads you to OS loader. If you install LILO, it
replace the MBR code to its own mini-OS loader, upon user selection, it them
jumps to whatever the OS loader the user selected.

Bi

-----Original Message-----
From: Moreira, Alberto [mailto:xxxxx@compuware.com]
Sent: Thursday, January 09, 2003 12:22 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Boot & System Volumes revisited

But in that case, how does for example LILO know where to boot from, when we
choose the Windows partition instead of the Linux one ?

-----Original Message-----
From: Peter Wieland [mailto:xxxxx@windows.microsoft.com]
Sent: Thursday, January 09, 2003 3:12 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Boot & System Volumes revisited

(using ravi's terminology here)

A drive with multiple partitions could have \Windows directories on
multiple of those partitions. My test machines are all setup with two
partitions, each of which has an installation. The system partition can
be found in this case by checking the active flag in the partition
information, but the boot volume cannot be derived from the partition
table alone.

In a system with multiple drives each of those drives could have a
partition set as active. In that case even examining the partition
tables doesn't tell you which is the system partition.

-p

-----Original Message-----
From: Moreira, Alberto [mailto:xxxxx@compuware.com]
Sent: Thursday, January 09, 2003 11:55 AM
To: NT Developers Interest List

This is an ignorant's question - I don't know much about Windows file
systems - but can't we know the boot volume by looking at the partition
table ? That's what I might do in a Linux system.

Alberto.

-----Original Message-----
From: Ravisankar Pudipeddi [mailto:xxxxx@windows.microsoft.com]
Sent: Thursday, January 09, 2003 2:49 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Boot & System Volumes revisited

"Boot volume" is the volume on which %SystemRoot% resides.
"System volume" is the volume off which the OS boots (i.e. containing
NTLDR and the boot sector).
Yes, the terminology is a bit misleading, but unfortunately, that's the
way it is.

If you find MS documentation indicating contrary, please send the link
to me, I'll forward it to our doc folks to fix.

Ravi

-----Original Message-----
From: Phil Barila [mailto:xxxxx@Seagate.com]
Sent: Thursday, January 09, 2003 10:49 AM
To: NT Developers Interest List
Subject: [ntdev] Boot & System Volumes revisited

I'm trying to ensure that a destructive disk utility I'm doing doesn't
whack disks that the OS depends on. I've figured out how to make sure I
don't wipe a volume with a page file, and the volume containing
%SystemRoot% is easy, too. However, the volume containing the boot
files is not, as far as I've been able to gather. I've seen a some
messages describing the definitions of Windows Boot & System Volumes,
and I've found a few things which don't seem to fit the models described
by others, so I'm hoping that someone can fill in the blanks.

I've seen reference to the boot volume being the place where ntldr,
NTDETECT.COM, and boot.ini reside, and the system volume being
%SystemDrive%, or the volume containing %SystemRoot%. Those don't seem
to be consistent with the display in Disk Management.

I did a test, as follows: I took an XP system, on which everything was
installed on C:, which is the Primary Master ATA device, NTFS. The XP
installation had all current updates, including SP1. There was a FAT32
D:, Primary Slave ATA device. The system also had a SCSI HBA with an
unformatted disk attached. If I looked at Disk Management, C: showed
"Healthy (System)".

I enabled INT13 on the SCSI HBA, but didn't change the BIOS boot order,
so the BIOS still orders the ATA drives ahead of the SCSI drive. Then I
took my handy-dandy MSDN DVD, put it into the DVD drive, and selected
Install XP Pro. I selected the unpartitioned SCSI disk space, installed
XP, then booted into the new installation, expecting to find that the
SCSI drive had become the system drive. I was quite surprised when I
looked at Disk Management. Now the old C: and D: are the same,
including C: showing (System). The SCSI drive is now F:, and it shows
(Boot). The single page file this installation is using is on F:, and
there is no ntldr, NTDETECT.COM, or boot.ini, in the root of F:. The
ntldr & NTDETECT.COM in
C: are now the RTM versions, and of course, C:\boot.ini was changed to
add the path to the new installation.

Just out of curiosity, I moved the ntldr, NTDETECT.COM, and boot.ini to
D:, then booted from a floppy with the same files. Same display in
Disk Management. Then I disabled the disk where C: resides, and it went
offline just fine. F: still shows (Boot). I restarted, and D: now
shows (System). I removed the boot files from D:, and restarted again.
D: still shows (System). Here's where I am at a loss to explain how the
"system" drive is determined. For this particular "Windows Session",
the "System" volume, if that is where the boot files reside, is A:.
More info, with C:\boot.ini unavailable, System Properties complains
that it can't find it when I click the Startup and Recovery button, and
then the default selector and the timeout editor are disabled.

I have a theory about the "System" volume, that Windows is defining the
first volume (partition) of whatever comes up as "\Device\HardDisk0" as
the "System" volume. Can anyone confirm this?

With all of this info, it appears that the most reliable way to keep
from whacking the voume where the boot files reside is to simply search
for them, and mark any partitions on which they are found as off-limits.
Anyone have a better idea?

Thanks,

Phil

Philip D. Barila
Seagate Technology, LLC
(720) 684-1842
As if I need to say it: Not speaking for Seagate.

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

The contents of this e-mail are intended for the named addressee only.
It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or
disclose
it to anyone else. If you received it in error please notify us
immediately
and then destroy it.

You are currently subscribed to ntdev as: xxxxx@microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.

You are currently subscribed to ntdev as: xxxxx@appstream.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

16

#4 - neither NTLDR nor NTDETECT are dependant on the type of hard-disk
controller that is present.

NTLDR goes through INT13 to access bios disks. If the ARC path in the
boot.ini file indicates that it needs to boot from a scsi drive then it
loads NTBOOTDD.SYS which is the scsi miniport for the controller
(hopefully) and uses that to access the drive.

-p

-----Original Message-----
From: David J. Craig [mailto:xxxxx@yoshimuni.com]
Sent: Thursday, January 09, 2003 1:34 PM
To: NT Developers Interest List

Microsoft has, as one reply indicated, a very confusing description/name
for this stuff. I think you know a lot of this, but I will try to
explain it as I understand it.

  1. The BIOS will look at hard drive 80h for the first sector to contain
    a signature of 0x55AA.
  2. It then load that sector into memory and the code within it looks
    for an active partition.
  3. That active partition’s boot record is loaded and executed.

Some BIOS’s permit drives other than 80h to be the boot drive either by
just doing it with a 81h or by swapping the drives around.

  1. If Windows XP, 2K, or NT the partition boot record loads NTLDR.
    That NTLDR or NTDETECT.COM or both are unique as to the type of hard
    drive controller running the boot drive. I understand that Microsoft
    has a IDE & SCSI version of the file(s).
  2. NTLDR parses the boot.ini file and uses the ARC names to find what
    and where to load.

I have written code that was loaded by the MBR, sector zero, and then
went out and found code to execute before even starting the OS. The was
a drive encryption product for DOS, but it could require that a password
be entered before the boot could continue. The partitions or parts of
the partitions were encrypted and had to be decrypted at the INT 13h
level.

----- Original Message -----
From: “Phil Barila”
Newsgroups: ntdev
To: “NT Developers Interest List”
Sent: Thursday, January 09, 2003 1:49 PM
Subject: [ntdev] Boot & System Volumes revisited

> I’m trying to ensure that a destructive disk utility I’m doing doesn’t
whack
> disks that the OS depends on. I’ve figured out how to make sure I
> don’t wipe a volume with a page file, and the volume containing
> %SystemRoot% is easy, too. However, the volume containing the boot
> files is not, as far
as
> I’ve been able to gather. I’ve seen a some messages describing the
> definitions of Windows Boot & System Volumes, and I’ve found a few
> things which don’t seem to fit the models described by others, so I’m
> hoping that someone can fill in the blanks.
>
> I’ve seen reference to the boot volume being the place where ntldr,
> NTDETECT.COM, and boot.ini reside, and the system volume being
> %SystemDrive%, or the volume containing %SystemRoot%. Those don’t
> seem to be consistent with the display in Disk Management.
>
> I did a test, as follows: I took an XP system, on which everything
> was installed on C:, which is the Primary Master ATA device, NTFS.
> The XP installation had all current updates, including SP1. There was

> a FAT32
D:,
> Primary Slave ATA device. The system also had a SCSI HBA with an
> unformatted disk attached. If I looked at Disk Management, C: showed
> “Healthy (System)”.
>
> I enabled INT13 on the SCSI HBA, but didn’t change the BIOS boot
> order, so the BIOS still orders the ATA drives ahead of the SCSI
> drive. Then I took my handy-dandy MSDN DVD, put it into the DVD
> drive, and selected Install
XP
> Pro. I selected the unpartitioned SCSI disk space, installed XP, then

> booted into the new installation, expecting to find that the SCSI
> drive
had
> become the system drive. I was quite surprised when I looked at Disk
> Management. Now the old C: and D: are the same, including C: showing
> (System). The SCSI drive is now F:, and it shows (Boot). The single
> page file this installation is using is on F:, and there is no ntldr,
> NTDETECT.COM, or boot.ini, in the root of F:. The ntldr &
> NTDETECT.COM in
> C: are now the RTM versions, and of course, C:\boot.ini was changed to

> add the path to the new installation.
>
> Just out of curiosity, I moved the ntldr, NTDETECT.COM, and boot.ini
> to
D:,
> then booted from a floppy with the same files. Same display in Disk
> Management. Then I disabled the disk where C: resides, and it went
offline
> just fine. F: still shows (Boot). I restarted, and D: now shows
(System).
> I removed the boot files from D:, and restarted again. D: still shows

> (System). Here’s where I am at a loss to explain how the “system”
> drive
is
> determined. For this particular “Windows Session”, the “System”
> volume,
if
> that is where the boot files reside, is A:. More info, with
> C:\boot.ini unavailable, System Properties complains that it can’t
> find it when I
click
> the Startup and Recovery button, and then the default selector and the

> timeout editor are disabled.
>
> I have a theory about the “System” volume, that Windows is defining
> the first volume (partition) of whatever comes up as
> “\Device\HardDisk0” as
the
> “System” volume. Can anyone confirm this?
>
> With all of this info, it appears that the most reliable way to keep
> from whacking the voume where the boot files reside is to simply
> search for
them,
> and mark any partitions on which they are found as off-limits. Anyone
have
> a better idea?
>
> Thanks,
>
> Phil
> –
> Philip D. Barila
> Seagate Technology, LLC
> (720) 684-1842
> As if I need to say it: Not speaking for Seagate.
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@yoshimuni.com To
> unsubscribe send a blank email to xxxxx@lists.osr.com

—
You are currently subscribed to ntdev as: xxxxx@microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

17

Isn't system root (or volume for that matter) indicated in boot.ini file?

Bi

-----Original Message-----
From: Phil Barila [mailto:xxxxx@Seagate.com]
Sent: Thursday, January 09, 2003 1:39 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Boot & System Volumes revisited

Not any MS documentation, just stuff here and on some newsgroups. It seems
that more than one person has tripped over the non-intuitive nature of this
terminology. "Inside Windows 2000, 3rd Ed." has it right.

However, as I detailed below, the system doesn't really identify the "System
Volume" as the place it booted from, because if it did, there would be some
indication of that in the event that you put ntldr, NTDETECT.COM, and
boot.ini on a floppy, and boot from that.

So really, how does Disk Management decide which volume it will label as
"(System)"? It's certainly not due to the presence of those three files.

(In the flattest Ben Stein I can muster)
"Anybody...? Bueller...?"

Phil

Philip D. Barila
Seagate Technology, LLC
(720) 684-1842
As if I need to say it: Not speaking for Seagate.

"Ravisankar Pudipeddi" wrote in message
news:xxxxx@ntdev...

"Boot volume" is the volume on which %SystemRoot% resides.
"System volume" is the volume off which the OS boots (i.e. containing
NTLDR and the boot sector).
Yes, the terminology is a bit misleading, but unfortunately, that's the
way it is.

If you find MS documentation indicating contrary, please send the link
to me, I'll forward it to our
doc folks to fix.

Ravi

-----Original Message-----
From: Phil Barila [mailto:xxxxx@Seagate.com]
Sent: Thursday, January 09, 2003 10:49 AM
To: NT Developers Interest List
Subject: [ntdev] Boot & System Volumes revisited

I'm trying to ensure that a destructive disk utility I'm doing doesn't
whack disks that the OS depends on. I've figured out how to make sure I
don't wipe a volume with a page file, and the volume containing
%SystemRoot% is easy, too. However, the volume containing the boot
files is not, as far as I've been able to gather. I've seen a some
messages describing the definitions of Windows Boot & System Volumes,
and I've found a few things which don't seem to fit the models described
by others, so I'm hoping that someone can fill in the blanks.

I've seen reference to the boot volume being the place where ntldr,
NTDETECT.COM, and boot.ini reside, and the system volume being
%SystemDrive%, or the volume containing %SystemRoot%. Those don't seem
to be consistent with the display in Disk Management.

I did a test, as follows: I took an XP system, on which everything was
installed on C:, which is the Primary Master ATA device, NTFS. The XP
installation had all current updates, including SP1. There was a FAT32
D:, Primary Slave ATA device. The system also had a SCSI HBA with an
unformatted disk attached. If I looked at Disk Management, C: showed
"Healthy (System)".

I enabled INT13 on the SCSI HBA, but didn't change the BIOS boot order,
so the BIOS still orders the ATA drives ahead of the SCSI drive. Then I
took my handy-dandy MSDN DVD, put it into the DVD drive, and selected
Install XP Pro. I selected the unpartitioned SCSI disk space, installed
XP, then booted into the new installation, expecting to find that the
SCSI drive had become the system drive. I was quite surprised when I
looked at Disk Management. Now the old C: and D: are the same,
including C: showing (System). The SCSI drive is now F:, and it shows
(Boot). The single page file this installation is using is on F:, and
there is no ntldr, NTDETECT.COM, or boot.ini, in the root of F:. The
ntldr & NTDETECT.COM in
C: are now the RTM versions, and of course, C:\boot.ini was changed to
add the path to the new installation.

Just out of curiosity, I moved the ntldr, NTDETECT.COM, and boot.ini to
D:, then booted from a floppy with the same files. Same display in
Disk Management. Then I disabled the disk where C: resides, and it went
offline just fine. F: still shows (Boot). I restarted, and D: now
shows (System). I removed the boot files from D:, and restarted again.
D: still shows (System). Here's where I am at a loss to explain how the
"system" drive is determined. For this particular "Windows Session",
the "System" volume, if that is where the boot files reside, is A:.
More info, with C:\boot.ini unavailable, System Properties complains
that it can't find it when I click the Startup and Recovery button, and
then the default selector and the timeout editor are disabled.

I have a theory about the "System" volume, that Windows is defining the
first volume (partition) of whatever comes up as "\Device\HardDisk0" as
the "System" volume. Can anyone confirm this?

With all of this info, it appears that the most reliable way to keep
from whacking the voume where the boot files reside is to simply search
for them, and mark any partitions on which they are found as off-limits.
Anyone have a better idea?

Thanks,

Phil
--
Philip D. Barila
Seagate Technology, LLC
(720) 684-1842
As if I need to say it: Not speaking for Seagate.

---
You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

---
You are currently subscribed to ntdev as: xxxxx@appstream.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

18

It hasn’t had to reside in a specific sector for a long time. However,
on drives which don’t support extended INT13, it does have to reside
within the space addressable with old INT13 calls (which is, I think,
the first 1024 cylinders of the drive).

The boot-loader code layed out at the beginning of each partition by
format contains enough information to locate NTLDR in the root directory
of that file system and attempt to invoke it. (this is why booting a
floppy formatted under NT results in the “couldn’t find NTLDR” message
on the screen)

-p

-----Original Message-----
From: Phil Barila [mailto:xxxxx@Seagate.com]
Sent: Thursday, January 09, 2003 2:51 PM
To: NT Developers Interest List

“Hardwired” wrote in message news:xxxxx@ntdev…

[snip]

> Also, those tree little files…
> are not just copied on the disk. At least one(ntldr) has to begin on a

> specific sector.

Umm, no, it doesn’t. I believe it used to, but at least in XP, it just
needs to be present in the root. You can verify this by copying those
three files to a floppy formatted by XP, then booting from that floppy.
No matter the order you copy them, it always boots OK on my test system.
It appears to be the same story if you remove those files from the boot
partition, then copy them back.

Phil
–
Philip D. Barila
Seagate Technology, LLC
(720) 684-1842
As if I need to say it: Not speaking for Seagate.
E-mail address is pointed at a domain squatter. Use reply-to instead.

—
You are currently subscribed to ntdev as: xxxxx@microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

19

Ok… you’re probably right. But when I tried to do it like this: remove
and copy… my system didn’t boot anymore… this is strange.
I didn’t made the floppy test… but I’m curious… shouldn’t you put in
some way MBR and EBR there? I know that in one of these two, most likely
EBR there is some information about the sector where ntldr is… ok,
forget about it. I didn’t worked too much with this… you look like a
more experimented guy… Mr. Seagate:)))… ok ok ok… I will not call
you like this anymore.

Thank you,
Hardwired

Phil Barila wrote:

“Hardwired” wrote in message news:xxxxx@ntdev…
>
>[snip]
>
>
>
>> Also, those tree little files…
>>are not just copied on the disk. At least one(ntldr) has to begin on a
>>specific sector.
>>
>>
>
>Umm, no, it doesn’t. I believe it used to, but at least in XP, it just
>needs to be present in the root. You can verify this by copying those three
>files to a floppy formatted by XP, then booting from that floppy. No matter
>the order you copy them, it always boots OK on my test system. It appears
>to be the same story if you remove those files from the boot partition, then
>copy them back.
>
>Phil
>–
>Philip D. Barila
>Seagate Technology, LLC
>(720) 684-1842
>As if I need to say it: Not speaking for Seagate.
>E-mail address is pointed at a domain squatter. Use reply-to instead.
>
>
>
>—
>You are currently subscribed to ntdev as: xxxxx@rdslink.ro
>To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>

20

Sorry I wasn’t talking about XP… NT4 and i think i made a test on
win2k too.

Phil Barila wrote:

“Hardwired” wrote in message news:xxxxx@ntdev…
>
>[snip]
>
>
>
>> Also, those tree little files…
>>are not just copied on the disk. At least one(ntldr) has to begin on a
>>specific sector.
>>
>>
>
>Umm, no, it doesn’t. I believe it used to, but at least in XP, it just
>needs to be present in the root. You can verify this by copying those three
>files to a floppy formatted by XP, then booting from that floppy. No matter
>the order you copy them, it always boots OK on my test system. It appears
>to be the same story if you remove those files from the boot partition, then
>copy them back.
>
>Phil
>–
>Philip D. Barila
>Seagate Technology, LLC
>(720) 684-1842
>As if I need to say it: Not speaking for Seagate.
>E-mail address is pointed at a domain squatter. Use reply-to instead.
>
>
>
>—
>You are currently subscribed to ntdev as: xxxxx@rdslink.ro
>To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>