We will try to cover some basics about device drivers today. It's such a vast and complicated topic, that it's just not possible to cover it well enough in our weekly study topics. So I will try to give you brief overview of what device drivers are, how they work and how they are developed.

In principle, device drivers are nothing but usual Windows 32 bit image files (similar to DLL's). Infact, you can use Depends (a tool that comes with Visual Studio), to look at the import/export sections of a device driver. NT Device drivers have a .sys extension, and developed using Windows Driver Development Kit (DDK).

There are two types of device drivers for specific streams of OS's, for Windows 9x based platforms, device drivers are called Virtual Device drivers (VxD's). These have a completely different format and usage. These are not simple Win32 PE files. For Windows NT based platforms, device drivers are usual .sys files having a PE image format. We will try to cover basics of NT device drivers in this topic.

Even windows NT device drivers now have two basic types. The NT legacy device drivers, and WDM device drivers. WDM stands for Windows Driver Model, and is a huge topic in itself. I will try to stick to NT legacy drivers in this session.

This entry point is called by the system as soon as the device driver is loaded. This get's two parameters as inputs. First one is called a Driver Object. It's an structure which is specific for this device driver, and contains each and every resource required for your driver including the despatch routines. The driver object is a sort of a bond between the OS and your driver. Using this driver object, the driver creates something called as device objects. Device objects are structures which store information about devices (actual physical devices). A driver creates as many device objects as the number of devices it handles. And all these are linked with the same driver object. So in principle, one driver has one driver object, and one or more device object.

Now the driver object has something called as despatch routines. There are the routines or functions called by the system at different points in the life cycle of a device drivers when it needs to send some IRP's to the driver. The device drivers sets these up in it's Driver Entry. There are a number of despatch routines, but the driver needs to setup only those which it's going to handle, the others, which it does not setup defaults to the system default routines. An IRP stands for Interrupt Request Packet. It's a way for the OS to communicate different things with the driver. Whenever the OS needs to communicate something to the driver, it prepares and sends an IRP to the driver. Now, the driver can handle these IRP's by registering a despatch routine for that particular IRP during it's Driver Entry. Hence, if there is such a despatch routine registered, the IRP gets sent to that and then the driver can handle that request by performing different operations specific with the device it is handling. So for example, there is an IRP called as IRP_MJ_CREAT. This get's sent to the driver when an application creates an instance of the device (using CreateFile). The driver can now perform specific tasks to setup communication with the device for the given application. Similarly, when the application closes the device handle (CloseHandle), an IRP, IRP_MJ_CLOSE, get's sent to the driver and driver can now do the cleanup etc. Similarly, there are IRP_MJ_READ, IRP_MJ_WRITE and hundreds more. You can find out more about IRP's and despatch routines in the Windows DDK.

An application communicates with the driver using something called as a symbolic link. A symbolic link is an string, which defines a name for the device, a driver is handling. The driver creates this symbolic link for the device object, when it created that in it's Driver Entry.

Now, lastly, we can look at a simple scenario of how an NT legacy device driver goes through different stages. Firstly, the driver is loaded when it's service is started. The driver's DriverEntry() get's called. The driver will perform all it's initialization tasks here, then it will create a device object for the device it is handling and also initialize the physical device. Next the driver will setup a symbolic link for this device. A symbolic link has a format something like \Device\MyDriver in kernel mode and translates to \\.\MyDriver in user mode. We have already seen these conventions in named pipes. Next the driver sets up different despatch routines. Now the driver will just wait for some request from the OS or the user mode applications. A user mode application can get a handle to the device driver (actually the device object), using CreateFile() on the symbolic link. This gets translated to an IRP_MJ_CREATE for the driver. Now there is a link established between the driver and the user mode application. The user mode application can now call functions such as ReadFile(), WriteFile(), which get's translated to IRP_MJ_READ, IRP_MJ_WRITE etc. The driver in despatch routines for these, will actually talk to the physical device, read/write the data to/from it and then fill up the user mode buffers provided. So the application can now use the physical device through it's driver. The application can then close the handle using CloseHandle().

As I said, even if you don't actually write a device driver, the knowledge of how these work is extremely useful in user mode too, specially for us, the system guys. There are a lot of low level work which you cannot do without having some basic knowledge about device drivers.

Bpath Counter