Peter Wieland: User Mode Driver Framework

Download this episode

Download Video


In Windows Vista, we have moved many drivers out of the kernel and up into user mode, which will greatly decrease the potential for blue screens and other bad things. As always, we love making Frameworks for developers that enable them to get things done faster, even for low level stuff like drivers.

You've learned about the Kernel Mode Driver Framework. In this video, we meet Peter Wieland who is the Development Lead for the User Mode Driver Framework (UMDF) team.  We have a conversation about many topics, but one of particular interest is why we are investing so much effort in making it easier to write drivers. Driver development is a very specialized programming niche, which requires deep knowledge of the underlining system as well sophisticated programming skills. Why open it up to the masses? Peter explains...

For more info:

WHDC’s site on UMDF - It has some white papers and WinHEC 2006 presentations including Peter's “Technical Synopsis” which has a PPT animation of how I/O flows through UMDF  (slides 10 and 11 show I/O flow for a kernel stack and then a user-mode stack.)

The UMDF beta is part of the Windows Drivers Kit (WDK) beta which can be joined at  Peter posted some instructions a while back on his blog about how to get into the WDK beta. 

Peter's blog is  "I’m not as active as I’d like to be, but there’s a long series there on DMA and drivers that folks seem to like."





Available formats for this video:

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

    The Discussion

    • Lon^
      Great interview, always good to hear more about driver dev and making it harder to crash the system!

      The only thing that does worry me is the eagerness to get managed code going. In one sense obviously it would be great to make drivers in a (relative to C) easy language. You get less errors and thus hopefully a better quality product but at what cost.

      I had a company laptop with a few managed services and they were certainly draining the memory. When this is taken into consideration with vista using 500MB (yeah I know its beta but still) even when idle and the fact the drivers will surely be slower anyway running in user mode it does make me a bit concerned.

      Fingers crossed for an easy to use and performant driver framework Smiley

    • stunna
      Wait, running drivers in user mode slows down processes?
    • Charles
      stunna wrote:
      Wait, running drivers in user mode slows down processes?

      What do you mean? Running drivers in user mode will incur some amount of performance cost given there's an extra step to getting data through the kernel which ultimately communicates with hardware...

      Great work has been done to proxy data from user to kernel extremely efficiently in Vista. Check out the video with Darryl Havens and other senior Windows architects here where this user-kernel communication process is explained.
    • Massif
      I'm sure I noticed that when I installed WMP11 one of the install steps was registering the User-Mode Driver Framework.

      Or words to that affect.

      Does this mean that the UMDF can be taken downstream, or is the installer talking rubbish? (Or me, it could be me talking rubbish)
    • CRPietschma​nn
      Is UMDF a set of .NET libraries? I mean, can you write device drivers in C#/VB.NET using UMDF? Or, does it still require writing device drivers in C++?
    • peterwie


      We're also concerned about the performance aspects of allowing managed drivers.  Keeping the footprint of an idle managed driver host low would be a priority of ours.  The best driver doesn't consume any resources when it's idle.

      One of the reasons i'm eager to get mangaged drivers working is actually to help with some of our performance issues.  Right now we run one host per device to provide isolation.  Iff the work the CLR team has done to improve app domains is as good as they say ( Smiley ), then we could potentially use those to isolate device stacks from each other and reduce the number of host processes required on a machine.

      Not that it's the only option for pooling, but it's an attractive one for a number of reasons.


    • peterwie

      The WMP 11 installer is speaking the truth.  UMDF is also being used by WMP on XP.

      The 1.0 version is for XP only (SP2 or later, or Windows Professional 2003 SP1 for x64) and it's used by the Media Transfer Protocol drivers that WMP ships.  The plan is that this will RTM in late Sept/early Oct of this year.  Although it's general release, it's an early snapshot of UMDF and i suggest anyone who really wants to use it wait for UMDF 1.5.

      The 1.5 version is for XP (same limitations as 1.0) and Vista and the redistributables will ship as part of the Vista WDK.


    • peterwie

      Currently UMDF requires that you write native code.  I have hopes that we'll be able to enable managed in the future, but for now it's C or C++.

      I imagine you could put together a native shim that would let you write a managed driver.  I don't honestly know if the interfaces we've defined will work through COM Interop or if you'd have to provide hand-built wrappers.

    • staceyw
      Charles wrote:
      stunna wrote: Wait, running drivers in user mode slows down processes?

      What do you mean? Running drivers in user mode will incur some amount of performance cost given there's an extra step to getting data through the kernel which ultimately communicates with hardware...

      Great work has been done to proxy data from user to kernel extremely efficiently in Vista. Check out the video with Darryl Havens and other senior Windows architects here where this user-kernel communication process is explained.

      Given that a kernel trans needs to happen either way, I wonder if usermode may (under some operations) be faster as it could possibly (with proper driver design) reduce the number of kernel transistions.  Just a thought.
    • peterwie

      You're correct that a user-to-kernel transition has to occur in both cases.  The difficulty with UMDF is that it then requires a kernel-to-user transition (to get the message up into the host process) which involves the scheduler.  Sending a request into a user-mode driver will always be slower than sending it to a kernel mode driver.

      However there are a number of things which make this more palatable.  First many devices are used sporadically and don't require huge amounts of throughput.  Take your typical input device (keyboard, mouse, joystick, etc...) - latency is a concern but throughput definately isn't.

      There are also techniques we can use to reduce the number of or cost of of context switches required for any given I/O that would help higher-throughput devices.  Batching of messages might be possible - though that's tricky when you don't know what the dependencies between the messages might be. Or an improved IPC mechanism could donate the remaining time slice from the sending thread to the receiving thread (just a random thought) to reduce the time introduced by thread scheduling.

      Finally the cost should continue to shrink relative to the computing power of the average PC.  You'll still have to pay for what you're getting (for the customer, isolation.  For the developer, ease of development & customers who like isolation) but the machine will have many more resources to pay with.


    • Lon^
      I realise you probably cant tell me this which I can perfectly understand I mean its not optimised yet etc but...

      Do you have any rough benchmarks at the moment comparing a user mode driver  to kernel mode and if so what were the results and the device being testing?

      On a seperate note, sorry if this is mentioned elsewhere but will the user mode process run at a higher priority to normal apps?
    • peterwie
      I don't like to provide comparison numbers because they're sort of silly.  It is a common question, but it's like asking whether a Porche or a diesel jetta is faster.  Kernel mode will always be faster if you're focussing on extreme performance.  However the question should be will UMDF be able to meet your requirements.

      That's also a question which can't be trivially answered since it all depends on your project - how many requests you need to send a second, how much data you need to transfer a second with those requests, what your required latency is, how much CPU and memory you need left over afterwards, etc...

      If you look at our WinHEC 2006 slides there's a slide on performance which has our "public" numbers.

      My suggestion with any new technology would be to do some simple prototyping to see if it can meet your requirements.  Take the skeleton sample, add a queue and some dispatch routines and mock up the interface your driver would expose to an app.  Then write a mock app that drives the device the way you think a typical application would, and measure the result.  If you can push the amount of data you need down, or if you can get notifications back within your latency requirements, and there's enough CPU left to do real work then UMDF is a good fit.  Otherwise you'll need to consider a kernel solution.

      I'm sorry that there's not an easy answer.

      On the second question - no.  UMDF drivers run at normal priority.  Note that your kernel mode drivers typically do as well (ignoring interrupt handling, but that's not really a "thread priority" thing).  We've considered looking at boosting the threads to see if we can decrease latnecy, but we also want to be sure that an errant driver can't starve the system for CPU time.

      Personally i think it's a little better than a kernel-driver.  For a KM driver you never know what priority you'll be running at since you're typically invoked in some arbitrary client thread.  So it's possible to end up with interesting priority inversion cases when you're acquiring locks.


    • mjones
      Good.  Thought, how about UMDF and  CE.  Maybe the design of a UMDF component could port to CE with changes done in  CE to support this and a changing a  KMDF to work in CE but at least you can get the UMDF to port.  In other words how to leverage UMDF to CE.  Being layered in CE of course performance but if you get the driver for "free" and it works great.

      -William Michael Jones
    • peterwie

      We've had some thoughts in that area too.  But I'll admit that i don't know enough about CE drivers, so i don't know if they're enough like Windows drivers to really benefit from WDF.  What do you folks think?

    • Dan

      more than 4 years later any news on managed code UMDF drivers ?

    Comments closed

    Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.