The Volume Parameter Block purpose and fields are not clear to me. It seems that there are contradictions between the WDK documentation and the Windows Internals book (5th edition). The WDK says:
"When a file system receives the volume mount request for a new volume, it creates a volume device object (VDO) for the volume. The VDO consists of a DEVICE_OBJECT plus an optional file-system-defined device extension. The newly created VDO forms the base of the file system volume stack for the new (or remounted) volume.
The file system mounts the volume by associating the VDO with the volume parameter block (VPB) for the corresponding storage device object and sets the VPB_MOUNTED flag on the VPB."
whereas the Windows Internals book explains that the volume manager is the one that creates volume device objects. inside the volume device object there is the VPB structure that has two pointers - deviceObject that points to the file system object that mounted the volume, and realDevice that is a back pointer to the volume device object.
according to the Windows Internals book, the purpose of the VPB is to connect the volume device object that was created by the volume manager to the file system object that mounted the volume. (if an applications asks for a file on a volume, IRP is sent to the volume device object, and then using the connecting VPB, to the file system object).
according to the WDK, the purpose of the VPB is to connect the volume device object
that was created by the file system driver to the physical device object in the device stack.
(what are the deviceObject and realDevice fields according to the WDK?)
whereas the Windows Internals book explains that the volume manager is the
one that creates volume device objects. inside >the volume device object
there is the VPB structure that has two pointers - deviceObject that
points to the file system object >that mounted the volume, and realDevice
that is a back pointer to the volume device object.
The WDK docs are calling the DeviceObject field of the VPB the, “file
system’s volume device object.” This would be distinct from the device
object that the volume manager creates to represent the volume. I suspect
that the WDK docs are using this naming convention since that’s what FAT and
NTFS call this device object (refer to the FASTFAT source for an example).
wrote in message news:xxxxx@ntfsd… > Hi All, > > The Volume Parameter Block purpose and fields are not clear to me. It > seems that there are contradictions between the WDK documentation and the > Windows Internals book (5th edition). The WDK says: > > “When a file system receives the volume mount request for a new volume, it > creates a volume device object (VDO) for the volume. The VDO consists of a > DEVICE_OBJECT plus an optional file-system-defined device extension. The > newly created VDO forms the base of the file system volume stack for the > new (or remounted) volume. > > The file system mounts the volume by associating the VDO with the volume > parameter block (VPB) for the corresponding storage device object and sets > the VPB_MOUNTED flag on the VPB.” > > whereas the Windows Internals book explains that the volume manager is the > one that creates volume device objects. inside the volume device object > there is the VPB structure that has two pointers - deviceObject that > points to the file system object that mounted the volume, and realDevice > that is a back pointer to the volume device object. > > according to the Windows Internals book, the purpose of the VPB is to > connect the volume device object that was created by the volume manager to > the file system object that mounted the volume. (if an applications asks > for a file on a volume, IRP is sent to the volume device object, and then > using the connecting VPB, to the file system object). > > according to the WDK, the purpose of the VPB is to connect the volume > device object > that was created by the file system driver to the physical device object > in the device stack. > (what are the deviceObject and realDevice fields according to the WDK?) > > can anyone shed some light on the issue? > > Thanks! > >
still, what is the purpose of the VPB? to connect the device object that is created by the file system to the physical device object in the device stack (WDK), or to connect the device object that is created by the volume manager to the device object that is created by the file system driver (Windows Internals)?
The purpose of the VPB is to connect the physical disk to the file system. Remember that pre PNP there had to be a way to make file systems removable, so this was done via the VPB. You could reformat a disk, dismount it, which cleared the FS instance out of the VPB, so that windows would go thru and try to mount a new File system over the disk.
still, what is the purpose of the VPB? to connect the device object that is created by the file system to the physical device object in the device stack (WDK), or to connect the device object that is created by the volume manager to the device object that is created by the file system driver (Windows Internals)?
NTFSD is sponsored by OSR
For our schedule of debugging and file system seminars
(including our new fs mini-filter seminar) visit: http://www.osr.com/seminars
They’re both right, really. The long answer is a bit complicated…
Prior to Vista we have two cases for media file systems: fixed media and
removable media.
*Pre-Vista Fixed Media*
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.
*Pre-Vista Removable Media*
Prior to Vista, there’s a wrinkle in that the volume manager does not get
involved with removable media. So, when you plug in a USB stick the
partition manager does not steal the partitions enumerated by the disk
driver and the volume manager does not create volume device objects.
Instead, the partition PDOs house the VPB and become the “RealDevice” field
in the VPB.
*Vista and later*
Vista and later remove the funny stuff when it comes to removable media, and
the volume manager gets involved with all partitions.
If you want to see any of this for yourself, you can always use DeviceTree:
wrote in message news:xxxxx@ntfsd… > still, what is the purpose of the VPB? to connect the device object that > is created by the file system to the physical device object in the device > stack (WDK), or to connect the device object that is created by the volume > manager to the device object that is created by the file system driver > (Windows Internals)? >
Thanks for the explanation! in all cases, the DeviceObject field in the VPB points to the device object created by the file system driver for this volume, am I right?
btw - regarding the *Pre-Vista Removable Media* case - if the volume manager does not create a device object for the volume, then where IRPs targeted at the volume go? usually, when a user mode application refers to a file on a volume
(e.g. CreateFile(“D:\test.txt”,…) an IRP is created and sent to the volume device object. from there (using the VPB) it goes to the file system device object. from there it goes to the physical device stack.
what is the sequence when the volume device object is not created?
>Thanks for the explanation! in all cases, the DeviceObject field in the VPB
points to the device object created by the file system >driver for this
volume, am I right?
Assuming a standard model where everyone is playing by the rules, yes.
btw - regarding the *Pre-Vista Removable Media* case - if the volume
manager does not create a device object for the volume, >then where IRPs
targeted at the volume go?
The FSD just talks to whatever is in Vpb->RealDevice, the FSD doesn’t care
where it came from or whose device object it is.
wrote in message news:xxxxx@ntfsd… > Thanks for the explanation! in all cases, the DeviceObject field in the > VPB points to the device object created by the file system driver for this > volume, am I right? > > btw - regarding the Pre-Vista Removable Media case - if the volume > manager does not create a device object for the volume, then where IRPs > targeted at the volume go? usually, when a user mode application refers to > a file on a volume > (e.g. CreateFile(“D:\test.txt”,…) an IRP is created and sent to the > volume device object. from there (using the VPB) it goes to the file > system device object. from there it goes to the physical device stack. > what is the sequence when the volume device object is not created? >
> whereas the Windows Internals book explains that the volume manager is the one that creates
volume device objects.
What kind of “VDO”? One is created by VolMgr, is a block device, and is named like \Device\HarddiskVolume%d.
Another is created by the FSD, is nameless and is associated with the first one by the VPB link.
Note: VPB is built by the IO manager, FSD knows not-so-much on it.
according to the Windows Internals book, the purpose of the VPB is to connect the volume device
object that was created by the volume manager to the file system object that mounted the volume.
Correct.
VPB link is automatically traversed on all CREATE calls, except the ones for READ_ATTRIBUTES.
> still, what is the purpose of the VPB? to connect the device object that is created by the file system to
the physical device object in the device stack (WDK), or to connect the device object that is created
by the volume manager to the device object that is created by the file system driver (Windows
Internals)?
> Vista and later remove the funny stuff when it comes to removable media, and
the volume manager gets involved with all partitions.
Really?
A: on my Srv2008 points at \Device\Floppy0, not at some VolMgr’s DO.
Vista+ really did some changes to these stacks, namely:
all MBR parsing (calling IoRead/WritePartitionTable) and all partitioning “drive layout” IOCTLs are now handled in PartMgr with Disk being unaware of them, Disk no more creates any partition PDOs
FtDisk renamed VolMgr
Dynamic Disk stack was a full replacement for FtDisk, and now is a plugin to VolMgr (named VolMgrX) which registers itself using some callbacks (seen this in the debugger). VolMgrX does not own the device objects.
Also, speaking about the removable media, the media detection mechanism used by the FSD (FASTFAT at least) is worth mentioning.
When the diskette is replaced while the files are open on it, FASTFAT retains the VolDO for the old diskette for some very long time. Attempts to do any work from these file handles causes the popup about “Please insert diskette XXXX”. I think this is the old MS-DOS’s behaviour carefully mimicked in WinNT.
This whole logic (the VerifyVolume path etc) is in FASTFAT and worth investigation, and VPB plays the major role in it.
> (e.g. CreateFile(“D:\test.txt”,…) an IRP is created and sent to the volume device object. from there
(using the VPB) it goes to the file system device object.
No.
Such CreateFile will check for VPB presence in IopParseDevice and will be automatically redirected to FS’s VolDo. And, if there is no such VolDO - then mount will be triggered.
The only non-redirected creates are the ones path-less (like \.\c:) and with FILE_READ_ATTRIBUTES desired access.
There is also an interesting side note with CDFS - opening \.\e: will open the CDFS’s VolDO, while opening the PnP device interface name for the CD/DVD drive will open the low-level CD/DVD device object (LUN PDO devnode) itself.
That’s why the Vista+ new CD IOCTLs - “exclusive mode” and such - require the PnP name (CDFS just fails them as unrecognized).
This is a much more detailed description (and good for the archives).
Floppies are a special case, though I had forgotten about them so much that
I didn’t even think of it
The fact that I was referring to is that volumes are now created for USB
sticks, prior to Vista this was not the case and the VPB used was the VPB
off of the partition PDO.
“Maxim S. Shatskih” wrote in message news:xxxxx@ntfsd… >> Vista and later remove the funny stuff when it comes to removable media, >> and >> the volume manager gets involved with all partitions. > > Really? > > A: on my Srv2008 points at \Device\Floppy0, not at some VolMgr’s DO. > > Vista+ really did some changes to these stacks, namely: > > - all MBR parsing (calling IoRead/WritePartitionTable) and all > partitioning “drive layout” IOCTLs are now handled in PartMgr with Disk > being unaware of them, Disk no more creates any partition PDOs > - FtDisk renamed VolMgr > - Dynamic Disk stack was a full replacement for FtDisk, and now is a > plugin to VolMgr (named VolMgrX) which registers itself using some > callbacks (seen this in the debugger). VolMgrX does not own the device > objects. > > Also, speaking about the removable media, the media detection mechanism > used by the FSD (FASTFAT at least) is worth mentioning. > > When the diskette is replaced while the files are open on it, FASTFAT > retains the VolDO for the old diskette for some very long time. Attempts > to do any work from these file handles causes the popup about “Please > insert diskette XXXX”. I think this is the old MS-DOS’s behaviour > carefully mimicked in WinNT. > > This whole logic (the VerifyVolume path etc) is in FASTFAT and worth > investigation, and VPB plays the major role in it. > > – > Maxim S. Shatskih > Windows DDK MVP > xxxxx@storagecraft.com > http://www.storagecraft.com > >
That’s definitely it. Prior to Vista, the partition manager only ignores
disks that have the FILE_REMOVABLE_MEDIA bit set. So if the device is doing
something funky then you’ll get the fixed media stack behavior.
“Maxim S. Shatskih” wrote in message news:xxxxx@ntfsd… >> The fact that I was referring to is that volumes are now created for USB >> sticks, prior to Vista this was not the case and the VPB used was the VPB >> off of the partition PDO. > > Depends on the kind of the stick maybe? I have the stick which shows > itself as non-removable disk. > > – > Maxim S. Shatskih > Windows DDK MVP > xxxxx@storagecraft.com > http://www.storagecraft.com > >
