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
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.