This resonse applies to W2K/XP/.NET Server. If you need to filter volumes for NT4 let me know and I’ll provide some more details.
Such a driver is an Upper Volume Filter Driver. Use the XP DDK Toaster Filter sample code as a template for such a driver. This code will also work just fine for W2K. Do not use the W2K toaster filter source as it has bugs. If you want to install it manually you can just create the following registry values under the driver’s service key:
Value Name Data Type Data
DisplayName REG_SZ Your upper-volume filter driver
Group REG_SZ Pnp Filter
ImagePath REG_EXPAND_SZ System32\DRIVERS\YourFilter.sys
Start REG_DWORD 0
Type REG_DWORD 1
ErrorControl REG_DWORD 1
Then you need to register with the PnP Manager as an upper filter on the volume class of devices. Add a registry value named “UpperFilters” to the key listed below (if the value doesn’t already exist). It should be a REG_MULTI_SZ value, and the actual data that you want to add (or to insert if the value already exists) is the name of the filter driver that you want to be an upper filter driver to the volume class, so the data to add is “YourFilter” (without the “.sys” extension). Add it as the first string in this REG_MULTI_SZ list of strings.
In RegEdt32.exe, you separate each string in a REG_MULTI_SZ with a carriage return so that each string is displayed on its own line in RegEdt32.exe’s GUI.
HKLM\SYSTEM\CurrentControlSet\Control\Class{71A27CDD-812A-11D0-BEC7-08002BE2092F}
To create a .inf file for a filter driver see the sample in “The Windows 2000 Device Driver Book, 2nd Ed.” See p. 367. Also see C:\DDK_XP\2600\src\general\toaster\inf\filter.inf
If you build the toaster filter sample, as is, and add these registry values, bingo, you’ll have a basic functional volume filter driver. You can easily filter other device classes by simply changing which device class you add your driver name to the UpperFilters (or LowerFilters) value. Neato, eh?
I/O at this level is simpler than at the file system level. Reads and writes consist of offsets and lengths and a MDL points to the payload. You don’t have any of the Fast I/O entry points. By registering with the PnP manager as a filter for a class of devices, the PnP Manager will automatically call your AddDevice() routine whenever such a device is created - you don’t have to do your own discovery. If you want to provide persistent service to volumes (across reboots) then you’ll need to be able to identify volumes at the time you attach to them to see if they’re a volume to which you were previously providing some service so that you can recommence providing your service. Identifying volumes across boots isn’t terribly intuitive, especially when you want to be able to uniquely identify them at the time you’re attaching to them (in AddDevice()). Volume device objects are created by two drivers, ftdisk.sys (for basic and old-style FT volumes) and dmio.sys (for volumes on dynamic disks - dynamic volumes). When dynamic volumes came along it became necessary to be able to identify volumes uniquely, and so a new driver, the mount manager (mountmgr.sys), was added (in W2K). The mount manager will assign unique volume names to each volume in the system, regardless of whether the volume has a mount point (drive letter or NTFS reparse point mount point) assigned to it. These unique volume names persist across boots, and they’re available to user mode (see Win32 call GetVolumeNameForVolumeMountPoint()). You should probably use these unique volume names when you’re filtering volumes if you want to provide persistent services to volumes. Unfortunately, these unique volume names are NOT assigned to the volume at the time your AddDevice() routine is called. But, you can obtain this unique volume name before anyone starts sending I/O to the volume device object that you’re attached to. The way you do this is to watch for a IOCTL_MOUNTDEV_LINK_CREATED IOCTL that will be sent to the volume device object (actually it’ll be sent to you since you’re filtering - you have to pass it on to the volume device object). This IOCTL is sent from the mount manager to a volume class driver to tell the volume class driver the unique volume name that the mount manager has assigned to the volume. You can simply extract the name and check it to see if it is a volume that you were providing persistent services to. The volume class drivers create symbolic links to the volume device object when they process IOCTL_MOUNTDEV_LINK_CREATED, so if you intercept and process this IOCTL before passing it on to the volume class driver you’ll be prepared to recommence your services before any real I/O starts hitting the volume.
Don’t count on process names and SIDs at this level to be exactly those that initiated I/O in user mode… Chances are that someone has queued I/O above you (or will at some time) and sent it to you in another context.
Hope that helped.
Nate Bushman
-----Original Message-----
From: Tan Sin Lam [mailto:xxxxx@lit.a-star.edu.sg]
Sent: Monday, September 23, 2002 8:56 PM
To: File Systems Developers
Subject: [ntfsd] A question on filter driver below FSD
Hi,
If I would like to have a filter driver below a file system driver (e.g.
NTFS or FAT), what should I call this device, Volume device filter driver? I
assume in this case, the filter driver will attach to
\Device\HarddiskVolumeX.
For this filter driver, is it possible to obtain process name that requested
the IRP?
And is it possible to obtain User SID when it receives an IRP?
What kinds of IRPs can it receive, is it the same IRPs as in file system
filter driver?
Any sample of volume device filter driver in the DDK or IFS Kit?
Sorry to ask many questions, as I haven’t done any volume device filter
driver before.
Regards,
Sin-Lam
You are currently subscribed to ntfsd as: xxxxx@powerquest.com
To unsubscribe send a blank email to %%email.unsub%%
