Types of Windows Drivers

There are two basic types of Microsoft Windows drivers:

User-mode drivers execute in user mode, and they typically provide an interface between a Win32 application and kernel-mode drivers or other operating system components.

For example, in WindowsВ Vista, all printer drivers execute in user mode. For more information about printer driver components, see Introduction to Printing.

Kernel-mode drivers execute in kernel mode as part of the executive, which consists of kernel-mode operating system components that manage I/O, Plug and Play memory, processes and threads, security, and so on. Kernel-mode drivers are typically layered. Generally, higher-level drivers typically receive data from applications, filter the data, and pass it to a lower-level driver that supports device functionality.

Some kernel-mode drivers are also WDM drivers, which conform to the Windows Driver Model (WDM). All WDM drivers support Plug and Play, and power management. WDM drivers are source-compatible (but not binary-compatible) across Windows 98/Me and Windows 2000 and later operating systems.

Like the operating system itself, kernel-mode drivers are implemented as discrete, modular components that have a well-defined set of required functionalities. All kernel-mode drivers supply a set of system-defined standard driver routines.

The following figure divides kernel-mode drivers into several types.

As shown in the figure, there are three basic types of kernel-mode drivers in a driver stack: highest-level, intermediate, and lowest-level. Each type differs only slightly in structure but greatly in functionality:

Highest-level drivers. Highest-level drivers include file system drivers (FSDs) that support file systems, such as:

File allocation table (FAT)

CD-ROM file system (CDFS)

Highest-level drivers always depend on support from underlying lower-level drivers, such as intermediate-level function drivers and lowest-level hardware bus drivers.

Intermediate drivers, such as a virtual disk, mirror, or device-type-specific class driver. Intermediate drivers depend on support from underlying lower-level drivers. Intermediate drivers are subdivided further as follows:

Function drivers control specific peripheral devices on an I/O bus.

Filter drivers insert themselves above or below function drivers.

Software bus drivers present a set of child devices to which still higher-level class, function, or filter drivers can attach themselves.

For example, a driver that controls a multifunction adapter with an on-board set of heterogeneous devices is a software bus driver.

Any system-supplied class driver that exports a system-defined class/miniclass interface is, in effect, an intermediate driver with one or more linked miniclass drivers (sometimes called minidrivers). Each linked class/minidriver pair provides functionality that is equivalent to that of a function driver or a software bus driver.

Lowest-level drivers control an I/O bus to which peripheral devices are connected. Lowest-level drivers do not depend on lower-level drivers.

Hardware bus drivers are system-supplied and usually control dynamically configurable I/O buses.

Hardware bus drivers work with the Plug and Play manager to configure and reconfigure system hardware resources, for all child devices that are connected to the I/O buses that the driver controls. These hardware resources include mappings for device memory and interrupt requests (IRQs). (Hardware bus drivers subsume some of the functionality that the HAL component provided in releases of the Windows NT-based operating system earlier than WindowsВ 2000.)

Legacy drivers that directly control a physical device are lowest-level drivers.

File systems driver design guide

This section of the WDK provides conceptual information related to file systems and filter drivers. For reference pages that describe the interfaces your driver can implement or call, see the File System Programming Reference.

File systems

File systems in Windows are implemented as file system drivers working above the storage system.

Every system-supplied file system in Windows is designed to provide reliable data storage with varying features to meet the user’s requirements. Standard file systems available in Windows include NTFS, ExFAT, UDF, and FAT32. A comparison of features for each of these file systems is shown in File System Functionality Comparison. Additionally, the Resilient File System (ReFS), available on Windows Server 2012 and later versions, offers scalable large volume support and the ability to detect and correct data corruption on disk.

Developing a new file system driver is almost always unnecessary, and requirements/specifications for new file system drivers are not predictable. To that end, this design guide does not cover file system development. If you do need to develop a new file system driver beyond those available in Windows, sample code is available as a model (see below).

File system filter drivers

A file system filter driver intercepts requests targeted at a file system or another file system filter driver. By intercepting the request before it reaches its intended target, the filter driver can extend or replace functionality provided by the original target of the request. Examples of filter drivers include:

• Anti-virus filters
• Backup agents
• Encryption products

Filter driver developers use the system-supplied Filter Manager, which provides a framework for developing filter drivers without having to manage all the complexities of file I/O. The Filter Manager simplifies the development of third-party filter drivers and solves many of the problems with the legacy filter driver model, such as the ability to control load order through an assigned altitude.

File system and filter sample code

A number of Windows driver samples are available, including samples for file system development and file system filter driver development. See Windows driver samples for a complete list.

File system filter driver certification

Certification information for File Systems and File System Filter Drivers is found in the Windows Hardware Lab Kit (HLK). Tests for File Systems and File System Filter Drivers are found in the Filter.Driver category of the HCK.

Additional resources

Along with this documentation and the sample code mentioned above, OSR offers a variety of resources for file system filter development, including seminars and community discussion forums such as the NTFDS forum.

What is a driver?

It is challenging to give a single precise definition for the term driver. In the most fundamental sense, a driver is a software component that lets the operating system and a device communicate with each other. For example, suppose an application needs to read some data from a device. The application calls a function implemented by the operating system, and the operating system calls a function implemented by the driver. The driver, which was written by the same company that designed and manufactured the device, knows how to communicate with the device hardware to get the data. After the driver gets the data from the device, it returns the data to the operating system, which returns it to the application.

Expanding the definition

Our explanation so far is oversimplified in several ways:

Not all drivers have to be written by the company that designed the device. In many cases, a device is designed according to a published hardware standard. This means that the driver can be written by Microsoft, and the device designer does not have to provide a driver.

Not all drivers communicate directly with a device. For a given I/O request (like reading data from a device), there are often several drivers, layered in a stack, that participate in the request. The conventional way to visualize the stack is with the first participant at the top and the last participant at the bottom, as shown in this diagram. Some of the drivers in the stack might participate by transforming the request from one format to another. These drivers do not communicate directly with the device; they just manipulate the request and pass the request along to drivers that are lower in the stack.

The one driver in the stack that communicates directly with the device is called the function driver; the drivers that perform auxiliary processing are called filter drivers.

Some filter drivers observe and record information about I/O requests but do not actively participate in them. For example, certain filter drivers act as verifiers to make sure the other drivers in the stack are handling the I/O request correctly.

We could expand our definition of driver by saying that a driver is any software component that observes or participates in the communication between the operating system and a device.

Software drivers

Our expanded definition is reasonably accurate but is still incomplete because some drivers are not associated with any hardware device at all. For example, suppose you need to write a tool that has access to core operating system data structures, which can be accessed only by code running in kernel mode. You can do that by splitting the tool into two components. The first component runs in user mode and presents the user interface. The second component runs in kernel mode and has access to the core operating system data. The component that runs in user mode is called an application, and the component that runs in kernel mode is called a software driver. A software driver is not associated with a hardware device. For more information about processor modes, see User Mode and Kernel Mode.

This diagram illustrates a user-mode application communicating with a kernel-mode software driver.

Additional notes

Software drivers always run in kernel mode. The main reason for writing a software driver is to gain access to protected data that is available only in kernel mode. But device drivers do not always need access to kernel-mode data and resources. So some device drivers run in user mode.

There is a category of driver we have not mentioned yet, the bus driver. To understand bus drivers, you need to understand device nodes and the device tree. For information about device trees, device nodes, and bus drivers, see Device Nodes and Device Stacks.

Our explanation so far over simplifies the definition of function driver. We said that the function driver for a device is the one driver in the stack that communicates directly with the device. This is true for a device that connects directly to the Peripheral Component Interconnect (PCI) bus. The function driver for a PCI device obtains addresses that are mapped to port and memory resources on the device. The function driver communicates directly with the device by writing to those addresses. However in many cases, a device does not connect directly to the PCI bus. Instead the device connects to a host bus adapter that is connected to the PCI bus. For example, a USB toaster connects to a host bus adapter (called a USB host controller), which is connected to the PCI bus. The USB toaster has a function driver, and the USB host controller also has a function driver. The function driver for the toaster communicates indirectly with the toaster by sending a request to the function driver for the USB host controller. The function driver for the USB host controller then communicates directly with the USB host controller hardware, which communicates with the toaster.

What is a good resource to get started with Windows file system driver development?

What is a good resource to get started with Windows file system driver development for a newbie?

6 Answers 6

OSR Online’s File System Resource page (and OSR Online in general):

The NTFSD mailing list/forum (also hosted by OSR):

And starting with Vista, the Windows Driver Kit (WDK), which used to be called the DDK, now includes the Installable File Systems (IFS) Kit:

Just a heads up — Windows file system development is extremely complex because the file system is tightly integrated with the Windows memory manager. It’s the kind of thing that people dedicate careers to. Just so you have an idea what you may be getting into.

You might try Windows Hardware Developer Central, which has links to blogs, newsgroups, books, and other useful resources for driver authors.

I also recommend downloading and installing the Windows DDK and exploring some of the included samples. There should be various skeleton drivers that can be used as starting points for your custom work.

For Windows drivers also see this blog: http://blogs.msdn.com/doronh/

For Linux based development, two good books come to mind: Linux Device Drivers and Linux Kernel Development. The Linux Device Drivers book can be a bit daunting so a good introduction to the Kernel is a useful starting point.

The source code of Windows implementation of ext2 file system might be useful.
But as Mike B correctly mention this is extremely complex area to enter, I would strongly suggest to learn some basic driver development concepts and write few not file system drivers before you start file system driver development.
If you do this for commercial use and not for learning purposes i would suggest outsourcing this work.This will be most cost effective way to go.

or any newer book you can find by an Art Baker. I read his NT Device Driver book about 10 years ago, and it finally made everything clear.

BTW, the books from 10 years ago or more/less still valid. You can’t use the examples, but the model has basically not changed — just gotten more complex in typical M$ fashion. The IRP stuff is all still valid.

The OSR stuff is good — but expensive. I think for a full understanding of the whole design Baker can’t be beat. Also, anyone reading this just trying to learn Windows drivers — I would avoid the NTFS stuff. its super complicated, and has nothing to do with what you need to accomplish a simple USB driver, or even a DMA device.