How to determine current boot disk in filter driver

OSR_Community_User · October 27, 2008, 5:52pm

I have the following dilemma that I’d appreciate some help with:

In my filter driver EvtIoRead() function, I check the very first read that comes in and check the target disk number with a IOCTL_STORAGE_GET_DEVICE_NUMBER Ioctl. If that comes back as Disk0, I assume that it’s the current boot disk and let that process normally without intervention. That all worked fine and dandy until I came to a configuration where Windows XP was booted and the boot disk was Disk1.

I need to find a new way to determine the current boot disk when the first read call comes in targeting it. Can anyone suggest an approach to accomplish this?

Any help would be appreciated. Thanks in advance!

OSR_Community_User · October 27, 2008, 8:49pm

I’m not sure what you call the boot disk (is it the disk with the system partition (that’s what I suspect) or the one with the boot partition (as the name might indicate))… Check out http://support.microsoft.com/kb/314470 for the official definition of system and boot volume.

However, if you can get the volume then you can use IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS to get the physical disk.

Regards,
Alex.
This posting is provided “AS IS” with no warranties, and confers no rights.

OSR_Community_User · October 28, 2008, 4:59am

> I need to find a new way to determine the current boot disk when the first read call comes in targeting >it. Can anyone suggest an approach to accomplish this?

DeviceObject->Flags & DO_SYSTEM_BOOT_PARTITION

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

OSR_Community_User · October 28, 2008, 9:46am

Thanks very much for the help! I’ll try checking that DO_SYSTEM_BOOT_PARTITION flag.

OSR_Community_User · October 28, 2008, 2:49pm

I’m not sure why, but checking the flags on the boot volume’s DeviceObject coming in only has DO_POWER_PAGABLE && DO_DIRECT_IO set, never DO_SYSTEM_BOOT_PARTITION.

OSR_Community_User · October 28, 2008, 2:58pm

Are you using the disk device object or the volume device object?

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

wrote in message news:xxxxx@ntfsd…
> I’m not sure why, but checking the flags on the boot volume’s DeviceObject coming in only has DO_POWER_PAGABLE && DO_DIRECT_IO set, never DO_SYSTEM_BOOT_PARTITION.
>
>
>

OSR_Community_User · October 28, 2008, 3:11pm

Ahh…I see where you’re going with this. It is a Disk Class upper filter so the device objects I’m looking at are disk device objects, not volume device objects. I’m guessing thats why I’m not seeing that DO_SYSTEM_BOOT_PARTITION flag set.

Can you suggest of a way to determine if the disk device object I’m looking at contains the boot partition?

OSR_Community_User · October 29, 2008, 5:28am

> Ahh…I see where you’re going with this. It is a Disk Class upper filter so the device objects I’m looking

at are disk device objects, not volume device objects. I’m guessing thats why I’m not seeing that
DO_SYSTEM_BOOT_PARTITION flag set.

Yes.

Can you suggest of a way to determine if the disk device object I’m looking at contains the boot
partition?

At what startup phase do you need this? boot?

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

OSR_Community_User · October 29, 2008, 9:03am

I need this information very early in the boot. The very first read call that gets sent to the Disk and goes through my filter would be ideal. Thanks.

OSR_Community_User · October 29, 2008, 9:08am

Can you assume that the first disk stack your filter sees is the boot disk stack?

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

wrote in message news:xxxxx@ntfsd…
>I need this information very early in the boot. The very first read call that gets sent to the Disk and goes through my filter would be ideal. Thanks.
>

OSR_Community_User · October 29, 2008, 9:17am

Is that an assumption that would hold up in the real world on just about any Windows XP machine configuration? If so, that’d be great and I wouldn’t need to discover the boot disk programmatically.

OSR_Community_User · October 29, 2008, 10:24am

I never saw this assumption violated.

OS load sequence:

boot loader is loaded
boot loader finds the proper boot (SystemRoot) volume
boot loaded mounts its mini-filesystem to it and loads:
kernel
hal
SYSTEM hive
all Boot start .sys binaries
NLS tables
boot loader jumps to the kernel entry point
the kernel initializes itself
the kernel initializes all Boot start drivers, first PnP, then non-PnP
the kernel determines the disk stack for the boot (SystemRoot) volume and creates the SystemRoot symlink
the kernel mounts the SystemRoot using PsLocateSystemDll call which calls ZwCreateFile on \SystemRoot\system32\ntdll.dll
the kernel initializes all non-Boot start PnP drivers
the kernel initializes all System-start non-PnP drivers
mounts of non-SystemRoot volumes occur around here, at least not earlier

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

wrote in message news:xxxxx@ntfsd…
> Is that an assumption that would hold up in the real world on just about any Windows XP machine configuration? If so, that’d be great and I wouldn’t need to discover the boot disk programmatically.
>

OSR_Community_User · October 29, 2008, 10:30am

I’m going to give that assumption a run. Thanks very much for your help on this Maxim!!

OSR_Community_User · October 29, 2008, 5:06pm

Unfortunately the same machine configuration that lead me down this road is also a configuration where the assumption stated above does not hold up. The first disk read going through my filter is not targeting the disk with the current boot partition!

The machine in question is a BootCamp MacPro with the Windows Vista 64 partition installed on disk located in drive bay 3 and a MacOS partition on disk located in drive bay 1. Yeah, weird configuration, but have to cover all bases with this.

Anyway, with this configuration, the first disk read that comes through my Disk Class filter driver is targeting disk0 but the Windows partition is on disk1.

So, I am back to square one to try and identify the disk holding the current boot partition…

rod_widdowson · October 30, 2008, 3:22am

I don’t think you picked up on Alexadru’s question:

I’m not sure what you call the boot disk (is it the disk with the system
partition (that’s what I suspect) or the one with the boot partition (as
the name might indicate))…

It sounds as though the first disk you see (the one with the OSX on it) *is*
the boot disk. (and so DO_BOOT_PARTITION). Windows is on the system
volume.

The way I look for the system volume is to open \SystemRoot and grab the
device object from the FO. Of course you cannot do that before you have the
filesystems, but you wouldn’t be here if this wasn’t a filesystem problem.

YMMV but this has been pretty reliable for me.

Rod

wrote in message news:xxxxx@ntfsd…
> Unfortunately the same machine configuration that lead me down this road
> is also a configuration where the assumption stated above does not hold
> up. The first disk read going through my filter is not targeting the disk
> with the current boot partition!
>
> The machine in question is a BootCamp MacPro with the Windows Vista 64
> partition installed on disk located in drive bay 3 and a MacOS partition
> on disk located in drive bay 1. Yeah, weird configuration, but have to
> cover all bases with this.
>
> Anyway, with this configuration, the first disk read that comes through my
> Disk Class filter driver is targeting disk0 but the Windows partition is
> on disk1.
>
> So, I am back to square one to try and identify the disk holding the
> current boot partition…
>

OSR_Community_User · October 30, 2008, 9:08am

Hi,

what Max said is true if you have a volume filter.
Indeed the very first VOLUME-based read access is normally around
the time the system loads ntdll.

Regarding DISK-based access prior to first volume access, these reads are
targeted to a disk’s MBR or extended partition tables, when the system
tries
to find out about partitions.
And the first DISK-based read is not necessarily for the boot disk.

Mine is a disk and volume filter. I use IoGetBootDiskInformation somewhere
around the time of volume-arrival and Max’ hint as fallback.

As your driver is disk filtering only, you could try
IoGetBootDiskInformation
somewhere around the time of first IRP_MJ_CREATEs for the disks.

Regards
Else

|---------±-------------------------------->
| | “Rod Widdowson” |
| | | | com> |
| | Sent by: |
| | bounce-342142-18867@li|
| | sts.osr.com |
| | |
| | |
| | 30.10.2008 08:21 |
| | Please respond to |
| | “Windows File Systems |
| | Devs Interest List” |
|---------±-------------------------------->
>--------------------------------------------------------------------------------------------------------------------------------------------------|
| |
| To: “Windows File Systems Devs Interest List” |
| cc: |
| Subject: Re:[ntfsd] How to determine current boot disk in filter driver |
>--------------------------------------------------------------------------------------------------------------------------------------------------|

I don’t think you picked up on Alexadru’s question:

> I’m not sure what you call the boot disk (is it the disk with the system
> partition (that’s what I suspect) or the one with the boot partition (as
> the name might indicate))…

It sounds as though the first disk you see (the one with the OSX on it)
is
the boot disk. (and so DO_BOOT_PARTITION). Windows is on the system
volume.

The way I look for the system volume is to open \SystemRoot and grab the
device object from the FO. Of course you cannot do that before you have
the
filesystems, but you wouldn’t be here if this wasn’t a filesystem problem.

YMMV but this has been pretty reliable for me.

Rod

wrote in message news:xxxxx@ntfsd…
> Unfortunately the same machine configuration that lead me down this road
> is also a configuration where the assumption stated above does not hold
> up. The first disk read going through my filter is not targeting the
disk
> with the current boot partition!
>
> The machine in question is a BootCamp MacPro with the Windows Vista 64
> partition installed on disk located in drive bay 3 and a MacOS partition
> on disk located in drive bay 1. Yeah, weird configuration, but have to
> cover all bases with this.
>
> Anyway, with this configuration, the first disk read that comes through
my
> Disk Class filter driver is targeting disk0 but the Windows partition is
> on disk1.
>
> So, I am back to square one to try and identify the disk holding the
> current boot partition…
>

—
NTFSD is sponsored by OSR

For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

You are currently subscribed to ntfsd as: xxxxx@utimaco.de
To unsubscribe send a blank email to xxxxx@lists.osr.com

OSR_Community_User · October 30, 2008, 3:49pm

> Indeed the very first VOLUME-based read access is normally around

the time the system loads ntdll.

I’m very much sorry, but my idea of “first accessed disk” was only tested on XP and 2003, never on Vista.

There is a file named “bootstat.dat” which holds, among other things, the information of whether Windows was started OK previous time or not so (for the loader to show the recovery menu in text mode if previous Windows start failed).

In XP, this file is in system32.

In Vista, it is in \boot directory, which belongs to the boot loader’s (System) drive and not to SystemRoot (Boot) drive.

I will not be surprised if Vista first accesses \boot\bootstat.dat and only then ntdll.dll

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com