The first WDF framework that I'll talk about is the UMDF (User-Mode Driver Framework). This framework allows the development of user-mode drivers. Currently, the supported devices are USB non-isochronous devices, like digital cameras, portable media players, cell phones, PDAs, etc. Isochronous devices are the ones that require the data rate to flow continuously and at a steady rate, e.g. webcams, and their drivers are developed using the Kernel-Mode Driver Framework (KMDF), which I'll analyse in one of my future posts.

The first thought that comes to somebody's mind, when he hears the term "user-mode driver" is that this driver is 1)going to be slow and it 2)might also have stability or security issues, since the code will not be loaded in the protected memory area, where the kernel resides. So, let's look at both these potential problems. First of all, we've conducted measurements that show that the bottleneck in user-mode drivers is not the overhead of the additional user-to-kernel mode transisions, but the hardware bus. UMDF's WinHEC 2006 presentation states that "UMDF can easily saturate a USB 2.0 bus' maximum speed of 480 megabits/sec"! So, clearly performance in not an issue in our case. In addition, regarding the security issue, I need to remind you that: 1)one user-mode process cannot corrupt the memory that belongs to any other user-mode process or to the kernel and 2)if a user-mode process crashes, then the system continues normally, whereas if a kernel component crashes, then the Blue Screen Of Death (BSOD) appears and the computer is halted. So, we understand that user-mode drivers are actually even more secure than kernel-mode drivers, because another process cannot cause them to crash and also even if they crash (e.g. because of a programmatic error), the rest of the system remains intact!

Now that we've gone through the original "fears" behind UMDF let's talk about its advantages:

  • Simplicity: A UMDF developer doesn't have to deal with difficult kernel-mode issues like page faults, thread context, Interrupt Request Level (IRQL), etc.
  • Easier programming model: UMDF drivers can be programmed using C++, Win32 API and COM, which are familiar concepts for application developers.
  • Easier debugging: A UMDF driver can be debugged using a user-mode debugger, which is faster and required only one machine, whereas kernel-mode debugging is conducted with two machines.
  • Greater stability: If a user-mode driver crashes, then the rest of the system remains intact, whreas the crash of a kernel-mode driver causes the apperance of the Blue Screen Of Death (BSOD). Also, after the crash of the user-mode driver, the user can restart the driver and continue working.
  • Greater security: A UMDF driver cannot corrupt the memory that belongs to the kernel or to any other process.

So, now it's time to understand, when it's better to use UMDF over KMDF or the opposite. Generally, you should use UMDF:

  • For protocol buses, e.g. USB (non-isochronous), IEEE 1394, IP
  • For software-only drivers, e.g. filters, virtual ports, etc.

On the other hand, you should use KMDF:

  • If there are more stringent timing issues, e.g. isochronous USB devices like webcams
  • When you need hardware access, e.g. DMA, interrupts, etc
  • When you need access to kernel data.

Of course, you can always create a hybrid driver that is consisted of both a UMDF and a KMDF part :)

For addition information in UMDF, I have gather a list of very useful links that don't only talk about UMDF's architecture, but also describe how to develop a user-mode driver.

  • The first link to start with should be Microsoft's UMDF website.This website includes the most information regarding UMDF that you'll currently find in the web, like:
    • An introduction to the UMDF
    • The UMDF FAQ (Frequently Asked Questions)
    • Three high-level UMDF overviews here, here and here.
    • A more advanced presentation that shows UMDF's architecture.
    • Two documents that provide an introduction to COM-Lite, which is a subset of COM that is used by UMDF: an introductory version and a more detailed version.
    • A very analytical presentation that describes UMDF's architecture, the driver's structure, as well as an insight of how to develop a driver. can be found here. This is currently the most in-depth analysis of UMDF.
  • For those, who prefer watching a video to reading a document, you can check Peter Wieland's channel9 interview.
  • For all those, who like reading blogs, UMDF has 3 relative blogs:
  • I think that the best and easiest tutorial, in order to develop a UMDF driver is provided by OSR: part 1 and part 2 (need subscription)
  • Of course, the WDK is always the definite reference for driver developers, since it provides both an overview of UMDF's architecture and also a reference for the supported interfaces and their use.
  • Finally, compact summary regarding UMDF can be found in the Wikipedia.
After going through all this material, I think that it's time to download UMDF 1.0 and start developing drivers! :) In my future posts, I'll also spend time about the component's of a UMDF driver, how they are related, and I'll go through the process of creating a driver.