KMDF

NTDEV
1

I could really learn to like KMDF, I think. I won’t have hardware for
another week yet, but the driver is ready to go. For a DMA-based PCI
capture device, I estimate that it has taken about a third of the time
that a traditional WDM driver would have.

I love that the APIs actually have a consistent naming scheme. When I
needed to get a device object from a file object, I could guess without
knowing beforehand (successfully) that I needed WdfFileObjectGetDevice.

I love that all of the objects can have context structures, in an
orderly and reasonable way, with well-defined cleanup semantics. That’s
a fabulous concept. I was trying to figure out where to tuck some
global data, since there was no driver context, when it finally occurred
to me that I could just ADD one to my WDFDRIVER. Simple.

I love that the hyperlinks in the documentation are so thorough. The
KMDF doc is great for browsing; one page leads to a few more, which lead
to a few more, etc. I find that a great way to learn, and I know that
it is a bear to set up a document that way.

I love that callbacks for which the return code is not useful are
prototyped to return void. There were many cases in WDM where it was
not clear whether an error return would ever be seen by anyone.

This is Good Stuff.

I would love to see a page in the doc that summarizes the order in which
the device/driver callbacks are called, and the triggers for those
callbacks. I’ve seen such a page in a PowerPoint slide from a couple of
years ago, but I never remember the URL.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

2

Thanks for the great feedback ;). I asked our doc writer about the
callback stuff. Did you check out whdc?
http://www.microsoft.com/whdc/driver/wdf/KMDF.mspx. There might be a
whitepaper on there that is what you are looking for.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Wednesday, June 21, 2006 4:17 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] KMDF

I could really learn to like KMDF, I think. I won’t have hardware for
another week yet, but the driver is ready to go. For a DMA-based PCI
capture device, I estimate that it has taken about a third of the time
that a traditional WDM driver would have.

I love that the APIs actually have a consistent naming scheme. When I
needed to get a device object from a file object, I could guess without
knowing beforehand (successfully) that I needed WdfFileObjectGetDevice.

I love that all of the objects can have context structures, in an
orderly and reasonable way, with well-defined cleanup semantics. That’s
a fabulous concept. I was trying to figure out where to tuck some
global data, since there was no driver context, when it finally occurred
to me that I could just ADD one to my WDFDRIVER. Simple.

I love that the hyperlinks in the documentation are so thorough. The
KMDF doc is great for browsing; one page leads to a few more, which lead
to a few more, etc. I find that a great way to learn, and I know that
it is a bear to set up a document that way.

I love that callbacks for which the return code is not useful are
prototyped to return void. There were many cases in WDM where it was
not clear whether an error return would ever be seen by anyone.

This is Good Stuff.

I would love to see a page in the doc that summarizes the order in which
the device/driver callbacks are called, and the triggers for those
callbacks. I’ve seen such a page in a PowerPoint slide from a couple of
years ago, but I never remember the URL.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

3

Well, my first KMDF driver is up and running, interrupts and common
buffer DMA and all. I should probably write up a blog entry about the
experience.

I thought I was an INF expert, but I had trouble with the INF this
time. I think part of it is an inconsistency between the use of:
[Driver.NTx86.Section] (actually Driver.NT$ARCH$.Section)
and
[Driver.NT.Section]
The samples seem to mix the two, and based on my experience, setup
doesn’t like the mixing. If you start out with NTx86, it wants that
every time. It didn’t catch the co-installer at all until I added the
suffix.

Isn’t the co-installer supposed to work even if another driver has
already installed it? I had trouble rerunning the installation unless I
erased the co-installer and all of its toys. Perhaps I missed an INF flag?

I was getting a null pointer dereference until I realized I had added a
call to WdfDeviceInitSetFileObjectConfig after my call to
WdfDeviceCreate. My advice: don’t do that.

Today, I was getting a breakpoint inside of wdf0100.sys with no other
message. It was inside my ISR DPC; I *think* this was caused by me
attempting to call WdfCompleteRequest while I held the interrupt
spinlock, but I would have expected a message or a bugcheck.

Overall, it all came together pretty well, ahead of schedule and under
budget.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

4

Yeah, for a first-time Windows driver, I’m enjoying KMDF. I come
from the Mac and Linux driver programming world, for the most part; I
like OS X’s model a lot (at least for PCI drivers, which is what I
mostly do), but KMDF comes pretty close as far as being
straightforward. I’m pleasantly surprised, and it looks like I
jumped in at the right point (WDF looks OK to me, but a bit finicky
from what I’ve heard).

INF files are another matter, though. If someone has come up with an
effective framework for basing INF/INX files off of, please let me
know, because guess 'n check from the sample driver INF/INX files is
a slow and painful process. Alternatively, if there’s even some good
straightforward documentation on what really needs to go in them for
KMDF drivers (especially the co-installer business, which is what I’m
getting hung up on too), I’d really be appreciative.

On Jun 30, 2006, at 6:29 PM, Tim Roberts wrote:

Well, my first KMDF driver is up and running, interrupts and common
buffer DMA and all. I should probably write up a blog entry about the
experience.

I thought I was an INF expert, but I had trouble with the INF this
time. I think part of it is an inconsistency between the use of:
[Driver.NTx86.Section] (actually Driver.NT$ARCH$.Section)
and
[Driver.NT.Section]
The samples seem to mix the two, and based on my experience, setup
doesn’t like the mixing. If you start out with NTx86, it wants that
every time. It didn’t catch the co-installer at all until I added the
suffix.

Isn’t the co-installer supposed to work even if another driver has
already installed it? I had trouble rerunning the installation
unless I
erased the co-installer and all of its toys. Perhaps I missed an
INF flag?

I was getting a null pointer dereference until I realized I had
added a
call to WdfDeviceInitSetFileObjectConfig after my call to
WdfDeviceCreate. My advice: don’t do that.

Today, I was getting a breakpoint inside of wdf0100.sys with no other
message. It was inside my ISR DPC; I *think* this was caused by me
attempting to call WdfCompleteRequest while I held the interrupt
spinlock, but I would have expected a message or a bugcheck.

Overall, it all came together pretty well, ahead of schedule and under
budget.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Questions? First check the Kernel Driver FAQ at http://
www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

5

> INF files are another matter, though. If someone has come up with an

effective framework for basing INF/INX files off of, please let me
know, because guess 'n check from the sample driver INF/INX files is

Take someone else’s (better Microsoft’s) INF from WINDOWS\INF and patch to your
needs. This works.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

6

Maxim S. Shatskih wrote:

>INF files are another matter, though. If someone has come up with an
>effective framework for basing INF/INX files off of, please let me
>know, because guess 'n check from the sample driver INF/INX files is
>
>

Take someone else’s (better Microsoft’s) INF from WINDOWS\INF and patch to your
needs. This works.

That technique doesn’t help very much with the KMDF coinstaller, however.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

7

Why not? If you read the KMDF help section “Installing the Framework’s
Coinstaller,” it outlines the additions you need to make to an INF to
get the KMDF coinstaller running on your device.

(the topic is located under KMDF -> Design Guid-> Installing a
Framework-base Driver -> Installing the Framework’s Coinstaller)

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Friday, June 30, 2006 5:16 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] KMDF

Maxim S. Shatskih wrote:

>INF files are another matter, though. If someone has come up with an
>effective framework for basing INF/INX files off of, please let me
>know, because guess 'n check from the sample driver INF/INX files is
>
>

Take someone else’s (better Microsoft’s) INF from WINDOWS\INF and patch
to your
needs. This works.

That technique doesn’t help very much with the KMDF coinstaller,
however.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer