Windows® Internals, Sixth Edition, Part 2

Every device object contains a VPB data structure, but the I/O manager treats VPBs as meaningful only for volume device objects. A VPB serves as the link between a volume device object and the device object that a file system driver creates to represent a mounted file system instance for that volume. If a VPB’s file system reference is empty (VPB->DeviceObject == NULL), no file system has mounted the volume. The I/O manager checks a volume device object’s VPB whenever an open API that specifies a file name or a directory name on a volume device object executes.

For example, if the Mount Manager assigns drive letter D to the second volume on a system, it creates a \Global??\D: symbolic link that resolves to the device object \Device\HarddiskVolume2. A Windows application that attempts to open the \Temp\Test.txt file on the D: drive specifies the name D:\Temp\Test.txt, which the Windows subsystem converts to \Global??\D:\Temp\Test.txt before invoking NtCreateFile, the kernel’s file-open routine. NtCreateFile uses the object manager to parse the name, and the object manager encounters the \Device\HarddiskVolume2 device object with the path \Temp\Test.txt still unresolved. At that point, the I/O manager checks to see whether \Device\HarddiskVolume2’s VPB references a file system. If it doesn’t, the I/O manager asks each registered file system driver via a mount request whether the driver recognizes the format of the volume in question as the driver’s own.

EXPERIMENT: Looking at VPBs

You can look at the contents of a VPB by using the !vpb kernel debugger command. Because the VPB is pointed to by the device object for a volume, you must first locate a volume device object. To do this, you must dump the volume manager’s driver object, locate a device object that represents a volume, and display the device object, which reveals its Vpb field.lkd> !drvobj volmgr Driver object (84905030) is for: \Driver\volmgr Driver Extension List: (id , addr) Device Object list: 84a64780 849d5b28 84a64518 84a64030 84905e00

The !drvobj command lists the addresses of the device objects a driver owns. In this example, there are five device objects. One of them represents the programmatic (control) interface to the device driver, and the rest are volume device objects. Because the objects are listed in reverse order from the way that they were created and the driver creates the control device object first, the first device object listed is that of a volume. Now execute the !devobj kernel debugger command on the volume device object address:lkd> !devobj 84a64780 Device object (84a64780) is for: HarddiskVolume4 \Driver\volmgr DriverObject 84905030 Current Irp 00000000 RefCount 0 Type 00000007 Flags 00001050 Vpb 84a64228 Dacl 8b1a8674 DevExt 84a64838 DevObjExt 84a64930 Dope 849fd838 DevNode 849d5938 ExtensionFlags (0x00000800) Unknown flags 0x00000800 AttachedDevice (Upper) 84a66020 \Driver\volsnap Device queue is not busy

The !devobj command shows the Vpb field for the volume device object. (The device object shown is named HarddiskVolume4.) Now you’re ready to execute the !vpb command:lkd> !vpb 84a64228 Vpb at 0x84a64228 Flags: 0x1 mounted DeviceObject: 0x84a6b020 RealDevice: 0x849d5b28 RefCount: 4311 Volume Label: OS

The command reveals that the volume device object is mounted by a file system driver that has assigned the volume the name OS. The RealDevice field in the VPB points back to the volume device object, and the DeviceObject field points to the mounted file system device object. You can use !devobj on this address to get more information on the mounted file system, as seen in the following output, which shows that NTFS has mounted the volume:lkd> !devobj 0x84a6b020 Device object (84a6b020) is for: \FileSystem\Ntfs DriverObject 84a02ad0 Current Irp 00000000 RefCount 0 Type 00000008 Flags 00040000 DevExt 84a6b0d8 DevObjExt 84a6bc00 ExtensionFlags (0x00000800) Unknown flags 0x00000800 AttachedDevice (Upper) 84a63ac0 \FileSystem\FltMgr Device queue is not busy

The convention followed by file system drivers for recognizing volumes mounted with their format is to examine the volume’s boot record (VBR), which is stored in the first sector of the volume. Boot records for Microsoft file systems contain a field that stores a file system format type. File system drivers usually examine this field, and if it indicates a format they manage, they look at other information stored in the boot record. This information usually includes a file system name field and enough data for the file system driver to locate critical metadata files on the volume. NTFS, for example, will recognize a volume only if the MBR partition Type field is NTFS (0x07), the Name field is “NTFS,” and the critical metadata files described by the boot record are consistent.