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.
BACKGROUND
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:
- The
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
- Processor
modes -- What's the difference between Ring 0 and Ring 3 in an x86
architecture system
- Memory
management - User mode, versus Kernel Mode. What we mean by "demand
paged virtual memory"
- What are
multiple, nested, interrupt levels
- The
difference between I/O port space and memory space
- Something
about how devices work: What a device register looks like, why/when
devices interrupt
- The
definition of "direct memory access" (DMA) and the basic differences
between DMA and programmed I/O relevant to a driver
What
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.
How
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.
Probably
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
be
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
"local"
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 OF
THE TRADE
What
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
Windows systems.
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.
What
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
supported.?
Don't even
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,
either.
?
What
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
download the
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
quite
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.
What
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
problems.
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.
Are
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 drivers.
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.
How
Do I Get Started Using The DDK?
Just like you'd do for any
Visual Studio project:?Install Visual Studio and the WDK on
your
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
driver development.
Where
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.
What's
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.
CREATING
YOUR DRIVER
There
Are Many Different Driver Models -- How Do I Know What KIND Of Driver I
Should Write?
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.
![x](data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" width="5" height="5"><rect fill-opacity="0"/></svg>){kind=small}
![](data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" width="18" height="18"><rect fill-opacity="0"/></svg>)
Post Your Comment![](data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" width="14" height="17"><rect fill-opacity="0"/></svg>)
