not getting IOCTL_DISK_GROW_PARTITION request in volume filter

OSR_Community_User · August 6, 2007, 5:52am

Hi,

I wrote a sample volume filter driver. My requirement is to identify/get notified when the volume gets extended. I am extending the volume using diskpart.exe. I have asserts in IRP_MJ_DEVICE_CONTROLs dispatch routine
ASSERT(IoStackLocation->Parameters.DeviceIoControl.IoControlCode != IOCTL_DISK_GROW_PARTITION ); and
ASSERT(IoStackLocation ->Parameters.DeviceIoControl.IoControlCode != IOCTL_DISK_UPDATE_DRIVE_SIZE );
But its not geeting hit.

When I handled that in disk filter driver, after extending a volume on basic disk first assert got hit. I dont know why it happened so ?

Do I need to register something in volume filter to get the IOCTL_DISK_GROW_PARTITION request ?

When I extended a volume on dynamic disk, both asserts never got hit in disk filter. What I observed is diskpart.exe works with Logical disk manager which creates a raw partition of extended size and maps it in original one maintaining its own database.

How volume filter can get either request or notification for the same ?

Thanks in advance.

Regards,

Pankaj

Get the freedom to save as many mails as you wish. Click here to know how.

Mark_Roddy · August 6, 2007, 6:43am

For dynamic disks ‘volumes’ are internal to the dmio driver and service. As
you noted, the entire disk (minus a bit at the end) is allocated for one
‘partition’ within which logical volumes are maintained. Your filter is not
going to see anything. It is possible that VDS might help and that you could
implement a VDS enabled app or service.

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of pankaj kale
Sent: Monday, August 06, 2007 5:52 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] not getting IOCTL_DISK_GROW_PARTITION request in volume
filter

Hi,

I wrote a sample volume filter driver. My requirement is to identify/get
notified when the volume gets extended. I am extending the volume using
diskpart.exe. I have asserts in IRP_MJ_DEVICE_CONTROLs dispatch routine

ASSERT(IoStackLocation->Parameters.DeviceIoControl.IoControlCode !=
IOCTL_DISK_GROW_PARTITION ); and

ASSERT(IoStackLocation ->Parameters.DeviceIoControl.IoControlCode !=
IOCTL_DISK_UPDATE_DRIVE_SIZE );

But its not geeting hit.

When I handled that in disk filter driver, after extending a volume on basic
disk first assert got hit. I dont know why it happened so ?

Do I need to register something in volume filter to get the
IOCTL_DISK_GROW_PARTITION request ?

When I extended a volume on dynamic disk, both asserts never got hit in disk
filter. What I observed is diskpart.exe works with Logical disk manager
which creates a raw partition of extended size and maps it in original one
maintaining its own database.

How volume filter can get either request or notification for the same ?

Thanks in advance.

Regards,

Pankaj

Get the freedom to save as many mails as you wish. Click
http:/yahoomail/tools/tools-08.html/> here to know how. — NTDEV is sponsored
by OSR For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars To unsubscribe, visit the List Server section of
OSR Online at http://www.osronline.com/page.cfm?name=ListServer</http:>

OSR_Community_User · August 6, 2007, 7:29am

Hi,

Thanks Mark.

I think for basic disks, I should get a IOCTL_DISK_GROW_PARTITION request in volume filter. But, currently I am not getting it. Do I need to register for this ?
If yes, How ?

-Pankaj

Mark Roddy wrote: v:* {behavior:url(#default#VML);} o:* {behavior:url(#default#VML);} w:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} For dynamic disks ‘volumes’ are internal to the dmio driver and service. As you noted, the entire disk (minus a bit at the end) is allocated for one ‘partition’ within which logical volumes are maintained. Your filter is not going to see anything. It is possible that VDS might help and that you could implement a VDS enabled app or service.

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of pankaj kale
Sent: Monday, August 06, 2007 5:52 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] not getting IOCTL_DISK_GROW_PARTITION request in volume filter

Hi,

I wrote a sample volume filter driver. My requirement is to identify/get notified when the volume gets extended. I am extending the volume using diskpart.exe. I have asserts in IRP_MJ_DEVICE_CONTROLs dispatch routine
ASSERT(IoStackLocation->Parameters.DeviceIoControl.IoControlCode != IOCTL_DISK_GROW_PARTITION ); and

ASSERT(IoStackLocation ->Parameters.DeviceIoControl.IoControlCode != IOCTL_DISK_UPDATE_DRIVE_SIZE );

But its not geeting hit.

When I handled that in disk filter driver, after extending a volume on basic disk first assert got hit. I dont know why it happened so ?

Do I need to register something in volume filter to get the IOCTL_DISK_GROW_PARTITION request ?

When I extended a volume on dynamic disk, both asserts never got hit in disk filter. What I observed is diskpart.exe works with Logical disk manager which creates a raw partition of extended size and maps it in original one maintaining its own database.

How volume filter can get either request or notification for the same ?

Thanks in advance.

Regards,

Pankaj

---------------------------------

Get the freedom to save as many mails as you wish. Click here to know how. — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

---------------------------------
Once upon a time there was 1 GB storage in your inbox. Click here for happy ending.

OSR_Community_User · August 6, 2007, 8:10am

Doesn’t this go to the ‘real’ disk device rather than to a disk
partition device? I think this IOCTL is targets at PhysicalDiskN rather
than e.g. C:

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of pankaj kale
Sent: Monday, August 06, 2007 7:29 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] not getting IOCTL_DISK_GROW_PARTITION request in
volume filter

Hi,

Thanks Mark.

I think for basic disks, I should get a IOCTL_DISK_GROW_PARTITION
request in volume filter. But, currently I am not getting it. Do I need
to register for this ?
If yes, How ?

-Pankaj

Mark Roddy wrote:

For dynamic disks ‘volumes’ are internal to the dmio driver and service.
As you noted, the entire disk (minus a bit at the end) is allocated for
one ‘partition’ within which logical volumes are maintained. Your filter
is not going to see anything. It is possible that VDS might help and
that you could implement a VDS enabled app or service.

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of pankaj kale
Sent: Monday, August 06, 2007 5:52 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] not getting IOCTL_DISK_GROW_PARTITION request in volume
filter

Hi,

I wrote a sample volume filter driver. My requirement is to
identify/get notified when the volume gets extended. I am extending the
volume using diskpart.exe. I have asserts in IRP_MJ_DEVICE_CONTROLs
dispatch routine

ASSERT(IoStackLocation->Parameters.DeviceIoControl.IoControlCode !=
IOCTL_DISK_GROW_PARTITION ); and

ASSERT(IoStackLocation ->Parameters.DeviceIoControl.IoControlCode !=
IOCTL_DISK_UPDATE_DRIVE_SIZE );

But its not geeting hit.

When I handled that in disk filter driver, after extending a volume on
basic disk first assert got hit. I dont know why it happened so ?

Do I need to register something in volume filter to get the
IOCTL_DISK_GROW_PARTITION request ?

When I extended a volume on dynamic disk, both asserts never got hit in
disk filter. What I observed is diskpart.exe works with Logical disk
manager which creates a raw partition of extended size and maps it in
original one maintaining its own database.

How volume filter can get either request or notification for the same ?

Thanks in advance.

Regards,

Pankaj

Get the freedom to save as many mails as you wish. Click here to know
how.
http:mail/yahoomail/tools/tools-08.html/> — NTDEV is sponsored by OSR For
our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars To unsubscribe, visit the List Server
section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Once upon a time there was 1 GB storage in your inbox. Click here for
happy ending.
http:mail/yahoomail/tools/tools-08.html/> — NTDEV is sponsored by OSR For
our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars To unsubscribe, visit the List Server
section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer</http:></http:>

OSR_Community_User · August 6, 2007, 1:07pm

Doesn’t this go to the ‘real’ disk device rather than to a disk partition device? I think this IOCTL is targeted at PhysicalDiskN rather than e.g. “C:”.

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of pankaj kale
Sent: Monday, August 06, 2007 7:29 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] not getting IOCTL_DISK_GROW_PARTITION request in volume filter

Hi,

Thanks Mark.

I think for basic disks, I should get a? IOCTL_DISK_GROW_PARTITION request in volume filter. But, currently I am not getting it. Do I need to register for this ?
If yes, How ?

-Pankaj

anton_bassov · August 6, 2007, 10:35pm

IOCTL_DISK_GROW_PARTITION is disk-related IOCTL that is defined in ntdddisk.h. Disks have their
partition tables, describing physical partitions on the disk. DISK.SYS creates a FDO for a disk
(named like "\DEVICE\HARDDISKx\DRx), plus PDOs for each partition of the disk
(named like "\DEVICE\HARDDISKx\ DP(y)0x7…)). Logical volumes are *mounted* on these physical partitions - they are not in the same stack (actually, these PDOs end up as standalone devices that are not on any stack). Instead, Ftdisk.sys that manages volumes on basic disks communicates with PartMgr.sys that attaches its devices to disk FDOs, via the proprietary interface.

When you grow the volume mounted on a partition of the basic disk, disk’s partition table has to be updated, so it receives IOCTL_DISK_GROW_PARTITION. Therefore, if you attach your filter to FDO that DISK.SYS has created, you are going to see this IOCTL. However, if you attach your filter to the volume that is managed by Ftdisk.sys, you are not going to see it, because Ftdisk.sys is not on the same stack with DISK.SYS.

Dynamic disks are from the totally different field - once they may be spread across multiple physical disks, there is no one-to-one correspondence between dynamic volumes and physical disk partitions.
Therefore, when you resize the dynamic volume, DISK. SYS just does not receive IOCTL_DISK_GROW_PARTITION.

I hope by now you already understand what stands behind the behaviour that you have described…

Anton Bassov

OSR_Community_User · August 7, 2007, 12:55am

Hi,

Thanks soviet.

But I am a bit confused with folllowing stack trace and what soviet wrote.
DiskPerf is a disk filter driver( From ddk sources with some modifications) . VolFlt is my volume filter driver.

IOCTL CODE was 0x70000 - IOCTL_DISK_GET_DRIVE_GEOMETRY
f76d5798 804eddf9 diskperf!DiskPerfDeviceControl+0x1b (FPO: [Non-Fpo]) (CONV: stdcall) [e:\winddk\3790.1830\src\storage\filters\diskperf\diskperf.c @ 1369]
f76d57a8 f99ccb90 nt!IopfCallDriver+0x31 (FPO: [0,0,0])
f76d5834 f99dd47f disk!DiskDeviceControl+0x55a (FPO: [Non-Fpo])
f76d5850 804eddf9 CLASSPNP!ClassDeviceControlDispatch+0x48 (FPO: [Non-Fpo])
f76d5860 f984a656 nt!IopfCallDriver+0x31 (FPO: [0,0,0])
f76d5894 804eddf9 ftdisk!FtDiskDeviceControl+0x6a4 (FPO: [Non-Fpo])
f76d58a4 f99c42a6 nt!IopfCallDriver+0x31 (FPO: [0,0,0])
f76d58b8 804eddf9 VolSnap!VolSnapDeviceControl+0x152 (FPO: [Non-Fpo])
f76d58c8 f97f2c56 nt!IopfCallDriver+0x31 (FPO: [0,0,0])
f76d58e8 804eddf9 volflt!VolFltDeviceControl+0x236 (FPO: [Non-Fpo]) (CONV: stdcall)
f76d58f8 f96c1c57 nt!IopfCallDriver+0x31 (FPO: [0,0,0])
f76d591c f96feffd Ntfs!NtfsDeviceIoControl+0x56 (FPO: [Non-Fpo])
f76d595c f9730827 Ntfs!NtfsGetDiskGeometry+0x5f (FPO: [Non-Fpo])
f76d5b78 f96e643b Ntfs!NtfsExtendVolume+0x210 (FPO: [Non-Fpo])
f76d5b8c f96e5859 Ntfs!NtfsUserFsRequest+0x341 (FPO: [Non-Fpo])
f76d5ba0 f96e57b3 Ntfs!NtfsCommonFileSystemControl+0x44 (FPO: [Non-Fpo])
f76d5c14 804eddf9 Ntfs!NtfsFsdFileSystemControl+0x116 (FPO: [Non-Fpo])
f76d5c24 f9761ee5 nt!IopfCallDriver+0x31 (FPO: [0,0,0])
f76d5c34 804eddf9 sr!SrFsControl+0x121 (FPO: [Non-Fpo])
f76d5c44 80573b42 nt!IopfCallDriver+0x31 (FPO: [0,0,0])
f76d5c58 805749d1 nt!IopSynchronousServiceTail+0x60 (FPO: [Non-Fpo])
f76d5d00 8056d370 nt!IopXxxControlFile+0x5e7 (FPO: [Non-Fpo])
f76d5d34 8053c808 nt!NtFsControlFile+0x2a (FPO: [Non-Fpo])
f76d5d34 7c90eb94 nt!KiFastCallEntry+0xf8 (FPO: [0,0] TrapFrame @ f76d5d64)

I saw many of the control codes showing similar stack.Few of them are
IOCTL_DISK_IS_WRITABLE
IOCTL_DISK_MEDIA_REMOVAL

Pankaj

xxxxx@hotmail.com wrote: IOCTL_DISK_GROW_PARTITION is disk-related IOCTL that is defined in ntdddisk.h. Disks have their
partition tables, describing physical partitions on the disk. DISK.SYS creates a FDO for a disk
(named like "\DEVICE\HARDDISKx\DRx), plus PDOs for each partition of the disk
(named like "\DEVICE\HARDDISKx\ DP(y)0x7…)). Logical volumes are *mounted* on these physical partitions - they are not in the same stack (actually, these PDOs end up as standalone devices that are not on any stack). Instead, Ftdisk.sys that manages volumes on basic disks communicates with PartMgr.sys that attaches its devices to disk FDOs, via the proprietary interface.

When you grow the volume mounted on a partition of the basic disk, disk’s partition table has to be updated, so it receives IOCTL_DISK_GROW_PARTITION. Therefore, if you attach your filter to FDO that DISK.SYS has created, you are going to see this IOCTL. However, if you attach your filter to the volume that is managed by Ftdisk.sys, you are not going to see it, because Ftdisk.sys is not on the same stack with DISK.SYS.

Dynamic disks are from the totally different field - once they may be spread across multiple physical disks, there is no one-to-one correspondence between dynamic volumes and physical disk partitions.
Therefore, when you resize the dynamic volume, DISK. SYS just does not receive IOCTL_DISK_GROW_PARTITION.

I hope by now you already understand what stands behind the behaviour that you have described…

Anton Bassov

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Once upon a time there was 1 GB storage in your inbox. Click here for happy ending.

anton_bassov · August 7, 2007, 1:48am

Apparently, you just make a (faulty) assumption that IOCTL_DISK_GET_DRIVE_GEOMETRY originator must necessarily be located on the top of the call stack, right? Please note that tracing the call stack alone in order to detect IOCTL originator does not lead you anywhere. A driver X may receive IOCTL A, and send IOCTL B to driver Y in context of the same thread while processing it. If your filter is attached to the driver Y, tracing the call stack alone at the moment your filter receives IOCTL B in order to detect IOCTL B’s originator just does not make sense, because the caller on top of the call stack has originated IOCTL A, rather than B, and sent it to the driver that has no relation to your filter whatsoever…

Therefore, your call stack trace must be related to the device stack one - the moment you see that
a driver on the call stack is not on the same device stack with your filter, you can be sure that you have detected your target IOCTL’s originator…

Anton Bassov

OSR_Community_User · August 7, 2007, 2:03am

Many Thanks Soviet.

Now, I am much clear about this.

Regards,
Mayur

xxxxx@hotmail.com wrote: Apparently, you just make a (faulty) assumption that IOCTL_DISK_GET_DRIVE_GEOMETRY originator must necessarily be located on the top of the call stack, right? Please note that tracing the call stack alone in order to detect IOCTL originator does not lead you anywhere. A driver X may receive IOCTL A, and send IOCTL B to driver Y in context of the same thread while processing it. If your filter is attached to the driver Y, tracing the call stack alone at the moment your filter receives IOCTL B in order to detect IOCTL B’s originator just does not make sense, because the caller on top of the call stack has originated IOCTL A, rather than B, and sent it to the driver that has no relation to your filter whatsoever…

Therefore, your call stack trace must be related to the device stack one - the moment you see that
a driver on the call stack is not on the same device stack with your filter, you can be sure that you have detected your target IOCTL’s originator…

Anton Bassov

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Unlimited freedom, unlimited storage. Get it now