Device driver programming projects

You can download specific samples individually, or you can download the entire ZIP archive about MB when we last checked, including more than sample drivers. We recommend you download the complete archive. Take your time and look through the samples. This will be time well spent. So… now you have the background info you need, and you have all the stuff you need to develop Windows drivers.

Many folks find this step confusing. The best driver model to choose is based on as many as three things. So take some time to make this decision.

Make the decision thoughtfully. Broadly speaking, there are two Windows driver models that apply for general use, and some Windows driver models that apply to specific devices.

These are only two simple examples. Windows has specific models for lots of other device types as well. Lacking a specific model for your device type, you can use one of the general-purpose models.

WDM is the old, historic, model for writing Windows drivers. Nobody should use this model anymore for writing new Windows drivers. Trying to write a new WDM driver in the 21st Century will do nothing but make you hate life.

Enough said? This is the second general-purpose driver model that Windows supports. WDF is a modern, pleasant, and dare I say it almost easy to use method for writing Windows drivers. One interesting thing about WDF is that it actually comes in three flavors, called Frameworks:. Using UMDF today is a bit of a problem.

UMDF V1 is the older model. UMDF V2. To be absolutely clear, this means that if you write a UMDF V2 driver, that driver can only be installed on systems that are running Windows 8. In short, unless you only need to support Windows 8. On the other hand, if you do only need to support Windows 8. We told you many people find this driver model stuff confusing. Fortunately, there are some simple rules that can help you decide the best driver model for your use. Here are those rules:.

In the Location field, enter the directory where you want to create the new project. Check Place solution and project in the same directory and select Create. Visual Studio creates one project and a solution. You can see them in the Solution Explorer window. The solution has a driver project named KmdfHelloWorld. Choose a configuration and platform for the driver project. For example, choose Debug and x For Name , enter "Driver. Select Add.

The Driver. Now that you've created your empty Hello World project and added the Driver. If you can't add Ntddk. DriverEntry is the entry point for all drivers, like Main is for many user mode applications. The job of DriverEntry is to initialize driver-wide structures and resources. In this example, you printed "Hello World" for DriverEntry , configured the driver object to register your EvtDeviceAdd callback's entry point, then created the driver object and returned. For more information about framework objects, see Introduction to Framework Objects.

For DriverEntry , we strongly recommend keeping the name as "DriverEntry" to help with code analysis and debugging. EvtDeviceAdd is invoked by the system when it detects that your device has arrived. Its job is to initialize structures and resources for that device. In this example, you simply printed out a "Hello World" message for EvtDeviceAdd , created the device object, and returned.

Generally, we recommend naming your driver's functions in this way to differentiate them from other drivers' functions. DriverEntry is the only one you should name exactly that. This example illustrates a fundamental concept of drivers: they are a "collection of callbacks" that, once initialized, sit and wait for the system to call them when it needs something.

Fortunately, to say "Hello World," you only needed to worry about driver and device creation. For this exercise, we choose Debug and x The IRP includes information about the operation that is being requested. A description of the IRP data structure can be found here. The description and usage of an IRP can go from simple to complex very easily, so we will only be describing, in general, what an IRP will mean to you. That article can be found here.

If they were going to build a house, they could have a common overall design and perhaps a common set of tools like their tool box. This includes things like power drills, etc. All of these common tools and overall design of building a house would be the IRP. Each of them has an individual piece they need to work on to make this happen, for example, the plumber needs the plans on where to put the pipe, how much pipe he has, etc. Once everyone has completed their job, they then complete the IRP.

The device driver we will be building will not be that complex and will basically be the only driver in the stack. There are a lot of pitfalls that you will need to avoid but they are mostly unrelated to our simple driver. It is hard to digest theory or even how code is supposed to work, without actually doing anything. You need some hands on experience so you can bring these ideas out of space and into reality.

The prototype for the DriverEntry is the following. We will simply be creating one device. The driver can use this location to store driver specific information. The next part is to actually put things in the DriverEntry routine. The first thing we will do is create the device. You may be wondering how we are going to create a device and what type of device we should create.

This is generally because a driver is usually associated with hardware but this is not the case. There are a variety of different types of drivers which operate at different levels, not all drivers work or interface directly with hardware.

Generally, you maintain a stack of drivers each with a specific job to do. The highest level driver is the one that communicates with user mode, and the lowest level drivers generally just talk to other drivers and hardware. There are network drivers, display drivers, file system drivers, etc. Each place in the stack breaks up a request into a more generic or simpler request for the lower level driver to service.

The highest level drivers are the ones which communicate themselves to user mode, and unless they are a special device with a particular framework like display drivers , they can behave generally the same as other drivers just as they implement different types of operations. As an example, take the hard disk drive. The driver which communicates to user mode does not talk directly to hardware. The high level driver simply manages the file system itself and where to put things. It then communicates where it wants to read or write from the disk to the lower level driver which may or may not talk directly to hardware.

There may be another layer which then communicates that request to the actual hardware driver which then physically reads or writes a particular sector off a disk and then returns it to the higher level.

It could then determine what sector read requests to service, however, it has no idea what the data is and does not interpret it. The first thing you will notice is the DbgPrint function. This data structure contains basically three entries. The first is the size of the current Unicode string, the second is the maximum size that the Unicode string can be, and the third is a pointer to the Unicode string.

This is used to describe a Unicode string and used commonly in drivers. Most Unicode strings passing into your driver will not be NULL terminated, so this is something you need to be aware of. Devices have names just like anything else.

The second parameter we passed 0, and it says to specify the number of bytes to create for the device extension. This is basically a data structure that the driver writer can define which is unique to that device. This is how you can extend the information being passed into a device and create device contexts, etc. We will not be using this for this example.

These requests are called IRP Major requests. There are also Minor requests which are sub-requests of these and can be found in the stack location of the IRP. What do these refer to? When communicating with the user-mode application, certain APIs call directly to the driver and pass in parameters!

So as you can see, when a user mode application uses these functions, it calls into your driver. That is true, these APIs can talk to any device which exposes itself to user mode, they are not only for accessing files. In the last piece of this article, we will be writing a user mode application to talk to our driver and it will simply do CreateFile , WriteFile , CloseHandle.

You can technically omit this function but if you want to unload your driver dynamically, then it must be specified. If you do not specify this function once your driver is loaded, the system will not allow it to be unloaded. We are simply setting the flags. I will explain this in the section on handling user-mode write requests. However, if you create a device in any function outside of the DriverEntry , you need to manually clear this flag for any device you create with IoCreateDevice. This flag is actually set by the IoCreateDevice function.

The last piece of our driver is using both of the Unicode strings we defined above. To put this into perspective, different vendors have different drivers and each driver is required to have its own name. You cannot have two drivers with the same NT Device name. Say, you have a memory stick which can display itself to the system as a new drive letter which is any available drive letter such as E:.

If you remove this memory stick and say you map a network drive to E:. How is this possible? Well, the driver needs to be able to interpret the requests and either handle them within themselves such as the case of a network redirector or pass them down to the appropriate hardware driver. This is done through symbolic links. E: is a symbolic link. This is how applications can be written using a commonly defined name which can be abstracted to point to any device driver which would be able to handle requests.

We can do whatever we wish to do, but in the end, however, the application attempts to use the device as how the device driver needs to respond and act. The next piece of code we will look at is the unload routine.

This is required in order to be able to unload the device driver dynamically. This section will be a bit smaller as there is not much to explain. You can do whatever you wish in your unload routine.

If this article is liked, I may write a second tutorial on implementing the IO Control function. If you have used WriteFile and ReadFile , you know that you simply pass a buffer of data to write data to a device or read data from a device. These parameters are sent to the device in the IRP as we explained previously.

The entry point simply provides the device object for the device for which this request is being sent for. If you recall, a single driver can create multiple devices even though we have only created one.

The other parameter is as was mentioned before which is an IRP! In our example, the only parameter we need from this is the length of the buffer provided to the driver, which is at Parameters. It starts the kernel build system and provides the kernel with information about the components required to build the module. A module built from a single source file requires a single string in the makefile.

The load target loads the build module and the unload target deletes it from the kernel. The resulting driver is named simple-module. To load the module, we have to execute the make load command from the source file folder. The added records look like this:. To verify, we can use the cat command to display the device file contents:.

You can find the full source code of this driver in the Apriorit GitHub repository. If you need a more complex device driver, you may use this tutorial as a basis and add more functions and context to it. Our developers have successfully delivered hundreds of complex drivers for Linux, Unix, macOS, and Windows.

Contact our experienced team to start working on your next Linux driver development project! By clicking OK you give consent to processing your data and subscription to Apriorit Blog updates. This article will be useful for developers studying Linux driver development. Related services Kernel and Driver Development. Character devices: 1 mem 4 tty 4 ttyS … Simple-driver …. You may also be interested in Get more posts like this. We'll send updates once a week. Tell us about your project Send us a request for proposal!

By clicking Send you give consent to processing your data.