Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

More Info on Driver Writing and Debugging

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:

How do Volume PDOs and VDOs get created?

TerrydaktalTerrydaktal Member Posts: 11


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


  • TerrydaktalTerrydaktal Member Posts: 11

    It appears that disk.sys creates PDOs for the partitions and when queried, it returns a DIID string that will cause partmgr to be loaded for the driver. Each time PartMgr is added with AddDevice and then StartDevice, it appears that this is when it will call the volume manager to do the volume PDO + VPB creation .

  • Scott_Noone_(OSR)Scott_Noone_(OSR) Administrator Posts: 3,260

    No, that diagram makes no sense. The partition manager is a filter driver that also acts as the partition bus driver. As from my previous post (9 years ago) it no longer steals partition PDOs created by disk but instead creates them itself.

    You’re asking lots of specific implementation details. What are you ultimately trying to do?


  • TerrydaktalTerrydaktal Member Posts: 11
    edited May 2019
    @"Scott_Noone_(OSR)" Well, I just want to know how it works on windows, for the sake of understanding the file system. It does look like ReactOS source code or WRK is the more appropriate thing to look at than go to a forum though.

    So It no longer steals PDOs (partition PDOs no longer exist) and just tells volume manager to create Volume PDOs as a filter driver like I said originally. Is there still a pseudo device on windows 8/10? . I'm on Windows 7. It seems that some diagrams show the volume PDOs directly above partmgr now
    but im convinced it is wrong
    Post edited by Terrydaktal on
  • TerrydaktalTerrydaktal Member Posts: 11
    edited May 2019
    Yes, because of spanned volumes, and hence it appears that the disk FDO is not connected to volume PDO by BusRelations but by Ejection Relations. This looks to be a good call : FltGetDiskDeviceObject
  • Scott_Noone_(OSR)Scott_Noone_(OSR) Administrator Posts: 3,260

    Correct, the Volume Manager is still a separate, root enumerated bus driver because you might need multiple partitions to make a single volume.

    For the other part of the equation, the file system device objects are not instantiated via PnP. The first time you try to open a device with a VPB the I/O Manager triggers mount processing and calls each registered file systems with an IRP_MJ_FILE_SYSTEM_CONTROL/FSCTL_MOUNT_VOLUME request. The file system then dynamically determine if their file system is on the media and, if it is, create the File System Volume Device Object (VDO) and shoves it in the VPB. See FASTFAT's handling of this request here:


  • TerrydaktalTerrydaktal Member Posts: 11

    So does FileObject->DeviceObject point to disk.sys FDO, I think potentially this is how the FS gets the original device object as the file object is referenced in the PDO. We all know that NtWriteFile uses FileObject->Vpb->DeviceObject to get the VDO and it sends the IRP to the top of the FS stack using IoGetAttachedDevice.

  • Scott_Noone_(OSR)Scott_Noone_(OSR) Administrator Posts: 3,260

    If the user opens C:\Foo.txt FileObject->DeviceObject points to the volume PDO. You're correct that FileObject->Vpb->DeviceObject points to the file system's VDO.

    The file system gets the volume PDO as part of FSCTL_MOUNT_VOLUME processing and uses IoGetAttachedDevice to get the top of the volume stack. This value is then cached in a per-volume structure called the Volume Control Block (VCB). The cached value is then subsequently used for all communication with the volume. Again, see FASTFAT source.


  • TerrydaktalTerrydaktal Member Posts: 11

    @Scott_Noone_(OSR) Thanks. The VCB is the VDO device extension right? I see Vcb->StorageDevice which looks to be the volume PDO which the file system passes to the volmgr stack using IoCallDriver to perform the write. I guess in the volume PDO is then where the link to the /Device/Harddisk0/DR0 disk.sys FDO is which was passed to the volume manager originally by partmgr.sys? The volume manager then calls the disk.sys stack.

    I've come across another question. What actually reports the arrival of a volume to the mount manager? A lot of sources say the disk class driver but I'm not sure that's correct.

    The class driver that created the storage volume calls IoRegisterDeviceInterface to register a new interface in the MOUNTDEV_MOUNTED_DEVICE_GUID interface class. When this happens, the Plug and Play device interface notification mechanism alerts the Mount Manager of the volume's arrival in the system. The Mount Manager responds to the arrival of a new storage volume by querying the volume driver for the following information: The volume's nonpersistent device object name (or target name), located in the Device directory of the system object tree (for example: "\Device\HarddiskVolume1"), the volume's globally unique identifier (GUID), also called the unique volume name and a suggested persistent symbolic link name for the volume, such as a drive letter (for example, "\DosDevices\D:")

    It makes it sound like the disk class driver that does this but I'm going to take 'volume driver' to mean volmgr. It would make sense if when volmgr is informed of partitions by partmgr, it would then query disk.sys using the device object passed to gather information and then it would inform mountmgr and pass the Volume GUID and the "\Device\HarddiskVolume1" name which is a volume name which disk.sys wouldn't be aware of, only volmgr comes up with this name for the Volume PDO, which is why I think disk.sys is not the one that informs mountmgr.

Sign In or Register to comment.

Howdy, Stranger!

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