How to determine the disk on which current volume resides

NTDEV
1

Hello Guys!

Can you please answer on my question. I have a volume filter and i want to add my device only to the specific stacks, for example, only on particular disks.

How can I determine during calling my volume filter’s AddDevice() on which disk resides constructing volume.

Before Windows 7 i used symlinks. I was enumerating all HarddiskX\PartitionY on the system and check target devices for them, and when target device name was equal to the AddDevice’s DeviceObject name I was stooping the search. After that i knew harddisk number on which current volume resided.

But beginning from Windows 7 following symlinks created later, and i can’t find the disk number using described approach.

Could anybody help me and answer how can i do it in other way?

Thanks in advance!

2

> How can I determine during calling my volume filter’s AddDevice() on which disk resides constructing

volume.

IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS returns you the disk number(s) of the partition(s) which constitute the volume.

But beginning from Windows 7 following symlinks created later

Yes. I think pre-Win7 they were created in FtDisk’s device creation path which is triggered by partition arrival notification from PartMgr, and in Win7, it is later.

Also note that at least in some older Windows (pre-Vista) the Harddisk%d\Partition%d were created by the Disk.sys itself initially, and then overwritten by FtDisk to point to HarddiskVolume%d.

This is not about Harddisk%d\Partition0, which is always created by Disk even in Win7 and is a synonim for \.\PhysicalDrive%d.

\ArcName is created even later, after the boot driver stacks start. The kernel’s loader block from the boot loader contains the table of (ArcName->MBR Signature), then the kernel enumerates all known disks, reads their MBR signatures and matches against the table. If the disk is found - then all existing partitions on it are registered in \ArcName too by using DiskArcName+partition(%d) format.

Then the boot ARC name (passed by the loader) is matched against \ArcName, and the matching volume is registered as \SystemRoot.

As about the boot drive letter creation - the drive-letter-based Win32 path of SystemRoot is kept in NtSystemRoot global, which references some absolute hardcoded address (I believe this to be the “shared user data” page which is shared with user processes).

Pre-Win7, this address is updated from IoAssignDriveLetters or something like, which seems to access \ArcName for this.

In Win7, it is updated by MountMgr in the undocumented IOCTL path, and updated by MountMgr scanning all known drive letters, opening each one and checking for DO_SYSTEM_BOOT_PARTITION.

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

3

Maxim, thanks! But, can i issue IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS control during AddDevice()? Device stack must be started by START_DEVICE before any request can issued, instead request finishes with status NO_SUCH_DEVICE.

4

> Maxim, thanks! But, can i issue IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS control during

AddDevice()? Device stack must be started by START_DEVICE before any request can issued,
instead request finishes with status NO_SUCH_DEVICE.

Then do your init at post-START DEVICE.

AddDevice is really very limited.

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

5

But After AddDevice my volume filter device is created and attached to volume stack and can’t be deleted and detached after that.

I can’t wait till START_DEVICE because i need that decision earlier when AddDevice is called… when i determine that destination disk is not that i want, i just skip volume filter device creation and attaching to the stack.

6

Your filter should always attach to the stack in AddDevice, and then during
completion of the start irp (because you need the layers below to be started
before you can use them) you can decide if you like the devices below you
(by sending it irps). If not, you stay attached and just pass everything
through. If you do like the lower device, you turn on filtering for it.

Jan

But After AddDevice my volume filter device is created and
attached to volume stack and can’t be deleted and detached
after that.

I can’t wait till START_DEVICE because i need that decision
earlier when AddDevice is called… when i determine that
destination disk is not that i want, i just skip volume
filter device creation and attaching to the stack.

7

> But After AddDevice my volume filter device is created and attached to volume stack and can’t be

deleted and detached after that.

It can be turned to no-op mode.

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

8

The general idea is to skip some disks is to allow attachment only on my disks, i.e. created by special miniport driver. I need this special attachment to allow update my driver without reboot. If I will attach my volume filter on every volume stack it will be unavailable to update driver without reboot.

9

Jan,

That is actually a terrible design for a high performance disk stack.
I do as the OP wants all the time, and only attach to devices/volumes I am
interested in. Doing the way you suggest degrades performance somewhere
between 5 to 10 percent in most cases.

To the OP, depending on where you attach you can issue IOCTL’s in
AddDevice. I would try your approach and see what you get. For instance I
commonly issue IOCTL_STORAGE_QUERY_PROPERTY in my AddDevice routines.

–
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

“Jan Bottorff” wrote in message news:xxxxx@ntdev…
> Your filter should always attach to the stack in AddDevice, and then
> during
> completion of the start irp (because you need the layers below to be
> started
> before you can use them) you can decide if you like the devices below you
> (by sending it irps). If not, you stay attached and just pass everything
> through. If you do like the lower device, you turn on filtering for it.
>
> Jan
>
>> But After AddDevice my volume filter device is created and
>> attached to volume stack and can’t be deleted and detached
>> after that.
>>
>> I can’t wait till START_DEVICE because i need that decision
>> earlier when AddDevice is called… when i determine that
>> destination disk is not that i want, i just skip volume
>> filter device creation and attaching to the stack.
>
>
>
> Information from ESET NOD32 Antivirus, version of virus
> signature database 4287 (20090729)
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
>

Information from ESET NOD32 Antivirus, version of virus signature database 4288 (20090729)

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

10

I’m not sure i agree with you Don. Issue of all requests to the not started device is a bad style, because device might not be initialized properly and every new OS version can brake that functionality.

Are there any other ideas Guys?