Filter drivers are optional drivers that add value to or modify the behavior of a device. A filter driver can service one or more devices.
Bus Filter Drivers:-
Bus filter drivers typically add value to a bus and are supplied by Microsoft or a system OEM (see the Possible Driver Layers figure). Bus filter drivers are optional. There can be any number of bus filter drivers for a bus.
A bus filter driver could, for example, implement proprietary enhancements to standard bus hardware.
For devices described by an ACPI BIOS, the power manager inserts a Microsoft-supplied ACPI filter (bus filter driver) above the bus driver for each such device. The ACPI filter carries out device power policy and powers on and off devices. The ACPI filter is transparent to other drivers and is not present on non-ACPI machines.
Lower-Level Filter Drivers
Lower-level filter drivers typically modify the behavior of device hardware (see the Possible Driver Layers figure). They are typically supplied by IHVs and are optional. There can be any number of lower-level filter drivers for a device.
A lower-level device filter driver monitors and/or modifies I/O requests to a particular device. Typically, such filters redefine hardware behavior to match expected specifications.
A lower-level class filter driver monitors and/or modifies I/O requests for a class of devices. For example, a lower-level class filter driver for mouse devices could provide acceleration, performing a nonlinear conversion of mouse movement data.
Upper-Level Filter Drivers
Upper-level filter drivers typically provide added-value features for a device (see the Possible Driver Layers figure). Such drivers are usually provided by IHVs and are optional. There can be any number of upper-level filter drivers for a device.
An upper-level device filter driver adds value for a particular device. For example, an upper-level device filter driver for a keyboard could enforce additional security checks.
An upper-level class filter driver adds value for all devices of a particular class.
What Is a File System Filter Driver?
A file system filter driver is an optional driver that adds value to or modifies the behavior of a file system. A file system filter driver is a kernel-mode component that runs as part of the Windows executive.
A file system filter driver can filter I/O operations for one or more file systems or file system volumes. Depending on the nature of the driver, the filter can mean log, observe, modify, or even prevent. Typical applications for file system filter drivers include antivirus utilities, encryption programs, and hierarchical storage management systems
File System Filter Drivers Are Not Device Drivers
A device driver is a software component that controls a particular hardware I/O device. For example, a DVD storage driver controls a DVD drive.
In contrast, a file system filter driver works in conjunction with one or more file systems to manage file I/O operations. These operations include creating, opening, closing, and enumerating files and directories; getting and setting file, directory, and volume information; and reading and writing file data. In addition, file system filter drivers must support file system-specific features such as caching, locking, sparse files, disk quotas, compression, security, recoverability, reparse points and volume mount points.
For more details on the similarities and differences between file system filter drivers and device drivers, see the following:
How File System Filter Drivers Are Similar to Device Drivers
The following subsections describe some of the similarities between file system filter drivers and device drivers in the Microsoft Windows operating system.
Similar Structure:-
Like device drivers, file system filter drivers have DriverEntry, dispatch, and I/O completion routines. They call many of the same kernel-mode routines that device drivers call, and they filter I/O requests for devices (that is, file system volumes) with which they are associated.
Similar Functionality:-
Because file system filter drivers and device drivers are part of the I/O system, they both receive I/O request packets (IRPs) and act on them.
Like device drivers, file system filter drivers can also create their own IRPs and send them to lower-level drivers.
Both kinds of drivers can register for notification (by using callback functions) of various system events.
Other Similarities:-
Like device drivers, file system filter drivers can receive Introduction to I/O Control Codes (IOCTLs). However, file system filter drivers can also receive--and define--file system control codes (FSCTLs).
Like device drivers, file system filter drivers can be configured to be loaded at system startup time or to be loaded later, after the system startup process is complete.
How File System Filter Drivers Are Different from Device Drivers
The following subsections describe some of the differences between file system filter drivers and device drivers.
No Power Management:-
Because file system filter drivers are not device drivers and thus do not control hardware devices directly, they do not receive IRP_MJ_POWER requests. Instead, power IRPs are sent directly to the storage device stack. In rare circumstances, however, file system filter drivers might interfere with power management. For this reason, file system filter drivers should not register dispatch routines for IRP_MJ_POWER in the DriverEntry routine, and they should not call PoXxx routines.
No WDM:-
File system filter drivers cannot be Windows Driver Model (WDM) drivers. The Microsoft Windows Driver Model is only for device drivers. For more information about file system driver development in Windows Me, Windows 98, and Windows 95, see the Windows Me Driver Development Kit (DDK).
No AddDevice or StartIo:-
Because file system filter drivers are not device drivers and thus do not control hardware devices directly, they should not have AddDevice or StartIo routines.
Different Device Objects Created:-
Although file system filter drivers and device drivers both create device objects, they differ in the number and kinds of device objects that they create.
Device drivers create physical and functional device objects to represent devices. The Plug and Play (PnP) Manager builds and maintains a global device tree that contains all device objects that are created by device drivers. The device objects that file system filter drivers create are not contained in this device tree.
File system filter drivers do not create physical or functional device objects. Instead, they create control device objects and filter device objects. The control device object represents the filter driver to the system and to user-mode applications. The filter device object performs the actual work of filtering a specific file system or volume. A file system filter driver normally creates one control device object and one or more filter device objects.
Other Differences:-
Because file system filter drivers are not device drivers, they do not perform direct memory access (DMA).
Unlike device filter drivers, which can attach above or below a target device's function driver, file system filter drivers can attach only above a target file system driver. Thus, in device-driver terms, a file system filter driver can be only an upper filter, never a lower filter.
Installing a File System Filter Driver:-
For Microsoft Windows XP and later operating systems, you should install your file system filter drivers by using an INF file and an installation application. (On Windows 2000 and earlier operating systems, filter drivers were commonly installed by the Service Control Manager.)
In the future, INF-based installation is expected to meet Windows Hardware Certification Kit requirements for file system filter drivers. Note that "INF-based installation" means only that you will need to use an INF file to copy files and to store information in the registry. You will not be required to install your entire product by using only an INF file, and you will not be required to provide a "right-click install" option for your driver.
Initializing a File System Filter Driver:-
The DriverEntry routine for initializing a file system filter driver is very similar to the DriverEntry routine for initializing a device driver. After a driver is loaded, the same component that loaded the driver also initializes the driver by calling the driver's DriverEntry routine. For file system filter drivers, the component that loads the driver is either the I/O Manager (for filters whose start type is SERVICE_BOOT_START) or the Service Control Manager (for other start types).
The DriverEntry routine runs in a system thread context at IRQL = PASSIVE_LEVEL. This routine can be pageable and should be in an INIT segment so that it will be discarded. For more information about how to make your driver code pageable, see the Remarks section of
MmLockPagableCodeSection.
The DriverEntry routine is defined as follows:
NTSTATUS
(*PDRIVER_INITIALIZE) (
IN PDRIVER_OBJECT DriverObject,
IN PUNICODE_STRING RegistryPath
);
This routine has two input parameters. The first, DriverObject, is the driver object that was created when the file system filter driver was loaded. The second, RegistryPath, is a pointer to a counted Unicode string that contains a path to the driver's registry key.
Attaching a Filter to a File System or Volume
A file system filter driver attaches itself to one or more mounted volumes and filters all I/O operations on them. But how does it determine which volumes to attach itself to? The sample filter drivers in the Windows Driver Kit (WDK) illustrate the two most common ways in which this is done:
The end user can specify the volumes to filter by, for example, typing in the drive letters for the volumes. The end user's commands are relayed to the filter driver as a private IRP_MJ_DEVICE_CONTROL request.
The file system filter driver can attach to one or more file system drivers, listen for IRP_MJ_FILE_SYSTEM_CONTROL, IRP_MN_MOUNT_VOLUME requests, and attach to volumes as they are mounted.
Note You should generally assume that the mapping of volumes to drive letters is one-to-many, not one-to-one. This is because of advanced storage features, such as dynamic volumes and volume mount points.
Note You should not assume that IRP_MN_MOUNT_VOLUME requests are always handled synchronously by the file system. For example, a floppy drive may be mounted asynchronously if there is no floppy disk in the drive. Thus your filter driver should be prepared to propagate the PendingReturned flag in its mount completion routine. For more information, see "Checking the PendingReturned Flag."
File system filter drivers can attach to, and filter I/O for, any file system volume. They cannot attach directly to storage devices, such as disk drives or partitions. Also, they cannot attach to individual directories or files.
