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.

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.

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/ .

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.
?

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.

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.

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.

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.

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.

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.

There
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."

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
installation.

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
Windows
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.Do
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.

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.

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..

Why wouldn't you?
There are some weird types of drivers that strictly speaking
do not
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
KMDF driver.

There are a surprising number of peer help forums. Check out the NTDEV
(for driver developers), NTFSD (for file system developers), and WINDBG
(for WinDbg debugger users) lists here at OSR Online. You must subscribe to
contribute. Note that you can choose to join these groups either as
traditional list server mailing lists, online or as private usenet news
groups. To do the latter, point your news reader to lists.osr.com. You
will be required to log in to these groups by providing your username
and password (that you specified when you joined) in order to post to
the group.

The people in all of these forums are generally very helpful.
Surprisingly often, the MS support folks or developers informally
answer questions on all these lists. All the lists expect you to do
your homework: Check the WDK documentation and the Microsoft Knowledge
Base, and be sure to read the group archives before asking your
question. Don't expect people in these groups to write your driver for
you.

A very useful publication is The NT Insider,
published every few months by OSR. One of the best things about it is
that it's free. Visit http://www.osr.com/ for your free
subscription.

Suppose
I Want To Pay for Help?

One option is
per-incident support from Microsoft's WDK Developer Support group. It's
relatively inexpensive, and the support people are typically very
helpful and know what they're doing.

There are also a significant number of companies that provide services
ranging from per-incident consulting to per-project design/build/test
pricing. The costs range from pretty inexpensive to stratospheric,
depending on whom you choose. In general (assuming you want to write
the driver yourself), we advise you to first exhaust the (free)
peer-support options and all possibility of help from Microsoft WDK
Developer Support before even considering paying anybody else for
assistance.

Question any company carefully as to their real hands-on skills and
experience in your specific type of driver before forking over your
money. Don't pay somebody who develops printer drivers for a living to
help you with your driver for a mass storage device. These two types of
drivers have fundamentally nothing in common. On the other hand, don't
engage a high-end expert firm to help you with your garden variety
simple driver. This is a bit like taking your Ford to a Ferrari
mechanic for a tune up. He can do it, but you'll wind up paying Ferrari
prices.

User Comments
Rate this article and give us feedback. Do you find anything missing? Share your opinion with the community!
Post Your Comment

"Getting Started"
Great introduction. Many Thanks.

Rating:
15-Jun-15, Claudius Modebe

"Awesome"
Very informative

Rating:
20-Mar-15, Vineel Kovvuri"nice site to learn"
if you fallow this site it will clarify your doubts about windows device drivers development. It is easy to learn things if you fallow in this way.

I want to develop a Windows driver for Virtual CD Drive. from where should I start? As mentioned in the article that DDK provided sample source codes for some drivers - are the Virtual Drive drivers included also?

Rating:
14-Jul-11, Ravi Gautam"Most Important Things To Know..."
In the article: "What Are The Most Important Things To Know About Writing Drivers?"

It is mentioned: "...you need to read Inside Windows whatever-is-the-most-recent-version."

Please note that most recent version of the "Inside Windows whatever-is-the-most-recent-version" book is currently titled: "Microsoft Windows Internals (4th Edition)..." This edition doesn't cover Windows Vista. However, the 5th Edition should be release in a week or two. that edition does cover Windows Vista.

Rating:
07-May-09, Bruce Olney"Useful information"
This article is useful for new beginner.

Rating:
29-Oct-06, Mike Dawn"'windowsupdate' for checked build"
Is there such a thing as windowsupdate.microsoft.com for the checked build? Or does that site cater to updating both normal and check builds?

Rating:
06-Feb-04, Richard Chan"test tools"
Are there not newer test tools available in the DDK? Looking for that "comprehensive list" you mention in Q22...