Updated 21 February 2014. Finally!
So you want to write Windows drivers, eh? Well, you've come to the right place. We'll give you some tips and "tell it like it is."
You might also find the article "Getting Starting Writing Windows Drivers" that appeared in the Jan/Feb 2014 Issue of The NT Insiderinteresting and useful... check it out here.
What Are Some Of The Key Concepts In Operating
Systems and Computer Science That I Need To Understand Before Learning
To Write Drivers?
You need to
understand some basics about operating systems and devices before you
can learn to write drivers. Here's a list of things you should know:
difference between wait locks versus spin locks, and why spin locks
might be used in an Operating System
- Threads and
processes: What these are in the Windows world versus the Unix world
- What we
mean by "thread safe", fully re-entrant, and MP safe
modes -- What's the difference between Ring 0 and Ring 3 in an x86
management - User mode, versus Kernel Mode. What we mean by "demand
paged virtual memory"
- What are
multiple, nested, interrupt levels
difference between I/O port space and memory space
about how devices work: What a device register looks like, why/when
definition of "direct memory access" (DMA) and the basic differences
between DMA and programmed I/O relevant to a driver
Are The Most Important Things To Know Abour Writing Drivers?
THE single most important things you need to know
are the basic architecture concepts of the Windows operating
system. This means that you must understand threading, serialization
and synchronization, IRQLs, the basic objects used in the I/O subsystem
(driver, device, etc), and the general flow of an I/O request through
the system. Writing drivers is not like writing most applications; you
absolutely cannot just find a sample and start hacking away at it to
make it do what you want. It simply won't work. You have to put the
work in up front to get a basic clue, or you'll be condemned to having
problem after problem with no idea of how to fix what you've done.
To brush-up on your Windows architecture, we recommend you pick up a
copy of the latest version of
Windows Internals by Russinovich,
Solomon, and Ionescu (as we're writing ths, that's the 6th Edition).
Read and understand Chapters 1 through 3 (up to bu tnot necessarily
including the section entitled "Advanced Local Procedure Calls"). To
understand something about the I/O facilities provided by Windows, you
can read Windows System
Programming by Johnson M. Hart. Chapter 1, 2, 4
and chapter 14 are the most relevant.
Trust me on this one. There are very few shortcuts.
Learn about the O/S. Then start to learn about how
to write drivers.
Do I Learn How To Write A Driver for Windows?
If you've written drivers for
Linux or one of the UNIX variants, and you're familiar with Windows O/S
concepts, you might be able to learn what you need to know by reading
the documentation provided with the Windows Driver Kit
(WDK). Get the most recent version of the WDK (see later question), and
read the section entitled Getting
Started with Windows Drivers. This
documentation is surprising good, and covers a very broad range of
topics. Over the years, the MSDN online docs on how to write Windows
drivers have evolved to the point that they are actually both quite
clear and helpful.
the best way to come up to speed on Windows drivers fast is to take a
seminar on the topic. Don't be too quick to dismiss this option, even
if you consider yourself pretty smart. Sure, it costs some money. But
Windows drivers are both complicated and confusing enough that it can
extremely helpful to have somebody brain-dump you with just the
required information. Also, if the person teaching the class has real
hands-on knowledge, they can probably save you lots of time by helping
you avoid some of the better-known "gotchas" that lurk in this space.
If you do opt to take a seminar, we don't recommend you take one from a
company. ?Ask around. ?We admit that we're partially
to the seminars we here at OSR teach (you can check them out here. (Almost
nobody (even experienced Windows
driver writers) takes one of these seminars and says it was a waste of
time. ?We?teach both private and public seminars all
over the world on a variety of topics.
Tools Do I Need To Write Windows Drivers?
A new version of the Windows Driver Kit (WDK) is
released with each new version of Windows. You can use the
new WDK version to build drivers for that new version of Windows, and certain older
For example, the WDK released
with Windows 8.1 will allow you to build drivers for Windows 7, Windows
8, and Windows 8.1 -- The Win 8 WDK lets you build drivers for Windows
versions back to Vista.
The tools for building Windows
drivers changed dramatically starting with the Win 8 WDK. ?At
that time, driver development took a vast leap into the future (er,
well, actually, the present) and became fully integrated with Visual
Studio. The only catch is that you need Visual Studio Professional
or better. Visual Studio Express Edition (the one that's
available free) will not work. Assuming you have the right
version of Visual Studio, you can download the WDK and install it as an
add-in to Visual Studio. That's all you need! You
can find all the info, including download links, at http://www.microsoft.com/wdk/ .
Do I have to use Microsoft's Compiler?
Face it: There is very little that you
really have to do in this world, besides breathe
and die. Strictly speaking, you do not have to use the MS VC++
compiler. A few brave souls over the past years have used other
compilers. But trying to use another compiler is best described as an
exquisitely painful exercise. The WDK header files use a significant
number of Microsoft specific features (such as language extensions,
pragmas, and the like). Writing drivers is hard enough. Trying to write
drivers using something other than the Microsoft compiler is really not
something that you want to try.
Language Can I Write Drivers In?
You write drivers for Windows in either C or
C++. C++ was only officially supported for most drivers starting with
Windows 8. ?And only a subset of C++ functionality is
think about trying to use another language. All the functions and data
types are only defined in C/C++ header files. There are no assembly
language definitions provided, so you can't use assembly language,
Debuggers Can Be Used for Driver Debugging?
WinDbg, Microsoft's standard
kernel mode debugger, comes with the WDK. If you want to download
WinDbg for stand-alone use, like for use in your test lab, you can also
latest version from?http://www.microsoft.com/wdk/. In general, WinDbg is a
powerful and reliable tool.
If you're just starting out in
the world of drivers, you probably should use WinDbg. You'll hear lots
of whining and carping about WinDbg from some of the "old hands" that
have been doing Windows driver development for years. While WinDbg is
reliable now, this has not always been the case.
Note that the general model for
debugging Windows drivers is to use two systems. Do not try to do it
any other way. Just get a second system, and connect the
debugger to it across the network (or using a 1394 or serial cable).
?Or user a VM on your development system if you're writing a
software only driver. But, to repeat, do not bother trying to
develop a driver using one system. Computers are cheap these
days. Yes, even in countries outside the US and Western
Europe. Get a second system.
Testing Tools Are Available?
The Windows operating system
contains the most powerful testing tool available, Driver Verifier.
Driver Verifier (usually,
referred to as just "Verifier") comprises special set of modules in the
operating system that carefully monitor the execution of specific
drivers. If Verifier detects an inconsistency, or any incorrect
operation, it will display a diagnostic message in the debugger and
then crash the system.
Driver Verifier is setup and
controlled using the utility verifier.exe, located in the Windows
system directory. Using verifier.exe, you can configure Driver Verifier
to monitor specific drivers (such as a driver that you are writing) for
Driver Verifier is best when
it's used throughout your entire debugging process. That is, you should
always have Verifier enabled for your driver on your test machine. As
you go through the process of adding functionality to or modifying your
driver, Driver Verifier will be there to watch your driver's actions.
It's important to realize that
Driver Verifier is essentially a passive monitor. That means that while
it might occasionally modify the information sent to your driver, it
mostly just watches what your driver does. Driver Verifier itself is
not a tester. It doesn't send any I/O requests to your driver.
Therefore, in order to make use of Driver Verifier, you will have to
send the broadest range of both valid and invalid I/O requests to your
driver. This will allow Driver Verifier to monitor your driver's
behavior in the broadest possible set of conditions.
There Other Test Tools, Besides Verifier?
Absolutely. A bunch of them.
Visual Studio has a powerful
Code Analysis feasture built-in. This will check to ensure
you aren't making all sorts of silly (and dangerous) coding areas.
The WDK header files are specially annotated to enhance the
checking the Code Analysis provides.
The WDK plug-in for Visual
Stuido includes another helpful tool called Static Driver Verifier. This tool examines your code and models its behavior to see
if it conforms to the various interface and architecture rules for
Windows even provides, for
free, an entire suite of tests call the Hardware Certification Kit.
This is a pretty big kit, and its rather cumbersome and
annoying to use. We therefore don't recommend you set this up
for basic driver testing.
Do I Get Started Using The DDK?
Just like you'd do for any
Visual Studio project:?Install Visual Studio and the WDK on
development machine. ?Start by building a sample project.
We suggest starting with a sample KMDF project, because KMDF
is almost certainly going to be the framework you'll be using for
Can I Get The Latest DDK?
Didn't I already answer this?
Go to ?http://www.microsoft.com/wdk/
and you'll find the links there.
This Checked Build Stuff?
Windows comes in two basic
flavors: (a) The normal distribution kit that everybody uses, and (b) A
special build that has debugging information in it. The build with
debugging information is for use by driver writers, and for diagnosing
serious system problems. This debug build is called the "Checked Build."
See the WDK's Getting
Started section, Guide to Using the Free and Checked Builds, for a full
run-down on what the checked build is, where you get it, and how to
best make use of it.
Are Many Different Driver Models -- How Do I Know What KIND Of Driver I
There are many different "models" for writing
drivers on Windows. Chosing a driver model will be the most
important decision you'll make abaout how your driver will be developed.
In short, there are special models and general
purpose models. Special models apply to specific types of
devices. For example, there's a specific model for network
adapters, one for storage controllers, and a different one for graphcis
drivers. If the device you'll be writing a driver for has
a model that's specific to that device type, you basically
have to use that model.
If the device for which you'll be writing a
driver does NOT have a dedicated driver model you want to use KMDF.
?KMDF is the WIndows Driver Foundation, Kernel Mode Driver
Framework. KMDF is the modern model for writing drivers for
most types of "generic" devices: USB, PCIe, and the like.
A few words on other driver models:
This is being written in 2014. ?There is an old,
annoying, model for writing drivers for "generic" devices that has been
around since when Windows was born. This old model is called
WDM, the Windows Driver Model.You do not want to write a WDM
driver. Did you hear what I said?
Really. You don't. KMDF has been around
for 7 years now. It's proven. It's reliable.
It works. And it's waaaay easier to use than WDM.
So forget the whole WDM thing.
Another framework that you probably don't want
to use is UMDF. Microsoft's guidance differs from our on
this, but we have good reasons. ?UMDF V1 is a difficult scheme
that uses C++ and a COM-Lite programming pattern. It's also
effectively being deprecated. ?UMDF V2 is great, it's just
like KMDF. In fact, UMDF V2 and KMDF share 95% of the same
syntax. The problem with UMDF V2 is, as of this writing, it
only supports Windows 8.1 and later.
So... Our advice is, stick with KMDF if you're
writing drivers for generic devices that don't have their own
"dedicated" Windows driver model.
Where Can I Get Driver Samples?
are almost 150 sample drivers downloadable from MSDN. ?You can
find them at http://code.msdn.microsoft.com/windowshardware.
?One things that's nice about these samples is that their
licenses are pretty lenient, meaning the license allows you to use the
sample as a starting place for your driver. ?On the other
hand, these samples are just like the typical sample code you
download from MSDN: They are very useful and highly instructive, even
if some of the code provided isn't always exactly "the best." Samples
are provided for all sorts of hardware drivers, filter drivers, and
software-only drivers. Heck, they even give you the source code to a
few of the drivers that are part of the Windows OS? including sources
for the FAT file system.
If you take a seminar, especially a lab seminar, you'll undoubtedly
walk away with one or more sample drivers.
If you don't see a sample that's similar to the type of driver you need
to write, ask one of the sources listed in "Where Do I Get Help."
How Do I Start Cranking Code?
source code sample driver for a device of similar type to the one that
you need to support. Assuming your license allows it, start by
modifying this driver.
I Write It, How Do I Install It?
You'll need to create an
installation control file (AKA a ".inf file") to get your driver
installed in the system. The .INF file is used by the setup program,
which is invoked from the "Add/Remove Hardware" option in Control
Panel. Yes, even if you're writing a driver that isn't directly
associated with any hardware, it's still installed from "Add/Remove
Hardware." Of course, if you want to get really fancy, you could write
an attractive GUI program that invokes your .INF file to do the
What Is WDM? WDF?
WDM stands for Windows
Driver Model. It's the old, crufty, annoying model that was used for
building Windows drivers in the old days (before 2005). ?You
don't want to use this for creating new drivers if you can help it.
WDF is the
Driver Foundation. It's the modern and easier way to write drivers for
generic devices that don't have their own dedicated device model.
?If you use it, you will like it.
I Include WDM.H or NTDDK.H?
You want to include
WDM.H. Though the definition has changed over the years, this header
contains all the definitions for the Windows Driver Model. WDM is the
"forward moving" model by which drivers are built. If it's not in WDM,
it's probably a legacy driver type or function, and you should probably
stay away from it.
I Want to Change The Way A Standard Driver Works
- Can I Modify The WDK Sample and Just Replace The Standard Windows
No! A million times no. This causes nothing but
The right way to modify the behavior of a standard Windows driver is to
write a filter driver. This driver can sit either above or below the
standard driver, and modify its behavior. You can even use this
approach to provide additional functionality.
Is Windows File Protection?
This is also called System File
Protection. It is the mechanism used insome versions of WIndows by
which Windows ensures that standard
system files (files in %systemroot% and below) are not modified. It's
generally not something you have to worry about these days..
Do I Have To
Support PnP In My Driver?
Why wouldn't you?
There are some weird types of drivers that strictly speaking
fall into the Plug and Play category (like file systems and
software-only drivers for monitoring things that happen in kernel
mode). But in general your driver has to support PnP. Even if
you're writing a driver for an ISA bus device on a dedicated process
control system, believe it or not... you'll be writing a PnP compatible
Do I Have To Support PnP, Even If My Device Can
Never Be Removed From The System?
Yes. PnP is the basic process by which
Windows finds devices. So even if your device is soldered
to the computer main board, or within the SoC, you're writing a PnP
Write My Driver First, and Add PnP Later?