The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.
Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/
The disk class driver FDO creates PDOs for the partitions on the disk. The partition manager filter steals the PDOs from the enumeration and secretly sends them to the volume manager FDO, which is a root enumerated ("pseudo") device. The volume manager picks through the partitions and creates volume PDOs for the various volumes that the partitions make up. These volume PDOs contain the VPBs and become the "RealDevice" field in the VPB.
here is the HDD on my system:
and here is the volmgr object:
Could someone explain, then, how partmgr actually 'steals' the PDO creation. Surely it means that the partmgr actually does the PDO creation in the DriverEntry or StartDevice routine when the FiDO gets loaded, or rather, it just calls the volume manager and it will do the volume PDO + VPB creation itself for a PDO it creates after reading from the disk to determine the amount of partitions.
I think, immediately after this, VolMgr reads from the VBR on the disk to ascertain the file system and then calls AddDevice on the file system and it attaches itself as an FDO to the stack. 'FltMgr' and 'cumon' seem to be added I'm not sure what they are but I assume they are hardcoded to be added as filters for ntfs so it doesn't consult the registry? How does it know the drivers aren't already running so it doesn't call driver entry again, are drivers' object names the file path of the driver and it searches for an existing object?
Then the VolMgr invokes some sort of call to the file system to create a VDO and perhaps passes the Volume PDO to the call so they get linked through the VPB. Not sure how it does this but perhaps it passes an IRP to the FDO the file system just attached to the Volume PDO to do so and it will create a VDO and link it to the Volume PDO via the VPB. (however it gets the volume PDO.. perhaps it's linked in the IRP or it gets it from the FDO->DeviceExtension->AttachedTo on the FDO passed to IoCallDriver).
Also, when the FS sends an IRP to the volume PDO, how does it get directed to the original stack? I know that before being sent to the FSD, C:\ gets resolved to a non persistent name \Device\HarddiskVolume1 in ??\Global and it uses ObOpenObjectByName on this name to get the Volume PDO and then it uses the VPB to get the FSD VDO and passes the IRP to the file system that owns that VDO. How does the IRP get to the original device stack? I.e. how is the address of the correct FDO of the disk.sys known? I think the IRP gets tagged with the Volume PDO before being sent to the FSD. Perhaps the Volume PDO contains a link to the FDO of disk.sys that was passed by partmgr that it accessed by going back one on the PDO->DeviceExtension->AttachedTo, it would make sense and explain how VolMgr reads from the disk in the first place to identify the file system.
I was clutching at straws trying to piece together the scenario based on what is possible rather than what actually happens. Perhaps someone who knows exactly how it is implemented can make some corrections
It looks like you're new here. If you want to get involved, click one of these buttons!
|Upcoming OSR Seminars|
|OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!||Kernel Debugging||30 Mar 2020||OSR Seminar Space|
|Developing Minifilters||15 Jun 2020||LIVE ONLINE|
|Writing WDF Drivers||22 June 2020||LIVE ONLINE|
|Internals & Software Drivers||28 Sept 2020||Dulles, VA|