Doron Holan - Kernel Mode Driver Framework

Download this episode

Download Video


It's hard to write kernel mode drivers. Real hard. In fact, it's hard to believe how hard it is. Well, the Windows Driver People have been working tirelessly to make it a little less hard (not easy) to write kernel mode drivers that won't hose your system. You know, blue screen of death and the like.  If you write kernel mode drivers you really should watch this video. You will be impressed with the work that has gone into the Kernel Mode Driver Framework. This framework abstracts some of the pain points away for driver developers giving them the freedom to concentrate on their algorithms related to device usability...

Find out more about KMDF and related technologies (and get the bits!)

KMDF Blog:

KMDF homepage:

KMDF bits (v1.1 right now):

WDF: (UMDF, verification tools):



Available formats for this video:

Actual format may change based on video formats available and browser capability.

    The Discussion

    • User profile image
      Good interview. And why use the word complicated so many
      times? For sure developing a kernel mode driver is not easy,
      but the speaker had a clear voice. Also I'd be cautious about
      those "write those 1000's lines of code in 5 minutes, and that
      will only be a couple lines now". Still the formalization into a state
      machine is interesting. Also I appreciated when the speaker said
      they're trying to be consistent. Good tools do not try to do your
      work, they help you do good work.
      How do the mini-drivers fit into this? Are they simply outdated?

      Managed code drivers? Sad Ark! One day will come when we'll
      spend long winter evenings around the fireplace, telling our
      great-great-grand-children (thanks to bio-engineering) odd stories.
      A long time ago, there were people who actually understood
      what's going on in an operating system. Those programmers
      left us a great legacy. Aaaahhh! More, more of those fairy
      tales!! Wink

      Who said Java was one of the greatest things that happened
      to the developer community? Perplexed
    • User profile image
      Awesome stuff - as someone who used WinDriver to develop kernel mode drivers I'm happy that MS have provided the same sort of framework for driver development. Although it sounds more far more complete and more useful.

      Now if only a really good, and easy to setup set of Debug tools could be developed - I'd be a really happy bunny. (Windbg and softice are good, but surely it can be made easier?)
    • User profile image
      Damn cool video. Doron, your voice and clarity of expression is too good.
      Liked the way you have taken care to name methods & objects (get/retrieve & set/assign) - Only a developer can understand these kind of issues Smiley

      Waiting eagerly for the screencast of those wonderful state machines....
    • User profile image

      pierre: I guess charles could have used a synonym for complicated, but in the end, writing a driver is complicated.  Unlike a user mode application where preemption doesn't happen that often on a UP machine, a driver can easily get preempted on the same thread.  You have to think about synchronization all the time in every's a tough thing to do...and the consequences are harsh Embarassed.

      Yes, it sounds crazy that 1000s of lines of code go away, but they do.  WDM had a ton of state changes which implied many similar actions.  KMDF formalized it and broke it down into actions w/only one purpose.  this makes the code much more compact.

      massif:  i have not heard good things about windriver, so i am glad we can meet a need in that space.  Debugability is important to our team.  The debugger team is a separate team from us (in a different org as well), so getting huge changes into the debugger is a bit hard.  We took the route of making a very extensive debugger extension (Wdfkd.dll) to make debugging easier.

      Gandalf:  yeah, the naming thing is totally geek Tongue Out.  You only appreciate once you have been bitten by inconsistent naming in the past.  I'm glad someone else appreciates it.  Hopefully we can do the screencast soon, right now getting vista out the door takes up alot of my time Big Smile

    • User profile image

      as for mini-drivers, i assume you mean drivers that fit into a port/miniport model like NDIS or SCSIPORT.  Those stay the same for now, but you won't likely see new port driver models that are not KMDF based.  KMDF fits into some existing models today as well.  For instance you can easily write an NDIS-WDM driver using KMDF to do all the WDM aspects.


    • User profile image
      > "I guess charles could have used a synonym for complicated"

      Nothing wrong with Charles, I was speaking of the overall video
      and associated posts.

      When complexity gets high, it becomes a requirement to
      formalize and structure well. In this sense the framework
      described sounds like a good help. On the other hand, it is
      expected from someone working on low-level device drivers to
      have the ability to deal with complexity. Still, it is always a good
      idea to write frameworks that lean naturally to good design
      and coding practices.
    • User profile image
      now this is a video I really would have liked in HD-quality, at least the first part Wink

      Thanks for another deeply appreciated gem. You almost make me want to 'like' writing drivers for win again...and thanks, doronh, for making me feel old (c/c++, assembler...) but expensive;)
    • User profile image

      Good interview! 
      I can't tell you how much time Doron has saved me via his valuable news group posts. 


    • User profile image
      hopefully we can do a screencast of the state machines to compensate for the low res shots in this video Wink.  need to work out all the IP issues before we do that though.

    • User profile image
      (1) Excellent.
      (2) What about hot pluggable KMDF components. 
      (3) Loved seeing the State machines.  Wonderful way you did that too d.
      (4) Isolation in the KMDF with garbage collection, smart pointers, COM in the kernel, etc.  More Isolation and better detection will even allow maybe recovery from the KMDF BSOD. What about ring 1 and/or 2 for KMDF to achieve isolation and for debugging  a recreatable memory access.
      (5) Loved hearing about the serial KMDF sample. Excellent.
      Devil Thank you d.
    • User profile image
      Ya know it seems like,  honostly we could maintain the integrity of the device writers by using better examples ya know....Cus one of the issues that I've found as a novice user, was that even with all the fancy frameworks, there were times that certain things required knowing how things were working on the inside.But with the drivers you know.... like in the DDK documentation.....  there's a reference to functions variables... all kinds of diagrams.when it comes down to the nitty gritty of actually making a working driver.The documentation leaves it at, well look through an example.Which is sometimes is good, but in this case, especially with the complexity of drivers.  This is soooooo f#@!% up....I strongly beleive in the method of working with little peices.... get the little pieces to work, and after you put all the little pieces together the whole picture becomes clearer....But it's hard to sift through the examples in the DDK and figure out whats a little piece.It's nice to strip the example.  Work with just a little and see what it does.Seems like we could step it down a notch for beginners, and just try a hello world type driver....Just something simple like,   is there anything plugged into a USB port.Then maybe if so, Then how many?Just something simple like that.....   not much just a little thing.dont worry about power, or if something got plugged in, or takin out, just what's there, and if anything, how many?And a lot of this came from the fact that I've been chewing this DDK over now for a couple months, and I've went to the University library, and there's books on how the brains work, the body, light waves, the physics, and molecular structures of atoms and all this stuff.And you get to where the driver books would be, and there's only one shelf, about shoulder width of old driver books for IBMsnothing with even a complete example where you could atleast do something little.and that's it.......   In a day in age where so much in life almost revolves around the drivers, and only one little shelf of ancient technology.It was really sad.Just seems like better examples would help out a lot more, than racking our brains on developing a driver framework.Ya know this driver things, really been kicking my (I need to watch my language). Use to think, that I just haven't been looking in the right places.But here lately, I mean I have been every where, and watching this video made me realize that we're just at the threshold of technology ya know.  Its just so new, and a black art like yall said.and ya just, ya know you're on your own.Cus even out of alllllllll these resource links.......  there's almost none that you can come away from as a novice, and get going with.The saddest part is......  this is only a hump.....  the device development is where everythings at ya know.The local university dont even teach a class on driver development.....   its freakin crazy man
    • User profile image
      Hi Doron,

         I wanted information regarding how do i use KMDF Driver frame work to write the Smart card reader driver.

      The main reason why i am asking is the Smart card API which is available takes 2 input parameters.
      The first parameter the pointer to the smart card extension
      and the second parameter is IRP.

      Now my question is how do i use these API's in KMDF driver model.
      I case of KMDF model , it doesnot use IRP ..instead used WDFREQUEST....

      Do we have new smart card library with the changes which caters with KMDf model ???


    Comments closed

    Comments have been closed since this content was published more than 30 days ago, but if you'd like to send us feedback you can Contact Us.