Introduction to the User-Mode Driver Framework (UMDF)
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:
- Peter Wieland's "Pointless Blathering" : Peter is the Development Lead for UMDF.
- Patman's "Travels with UMDF": Patrick is a working with UMDF and he'll be presenting a hybrid 1394 driver that has both UMDF and KMDF components.
- My blog: After I finish with the overview of the driver models, I'll focus on UMDF driver development.
- 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.
Comments
Anonymous
October 11, 2006
can i write lower level filter driver with umdf ?Anonymous
October 12, 2006
No, the UMDF driver has to be at the top of the stack. The rest of the drivers have to be in the kernel. So, you can have an UMDF upper-level filter or a UMDF function driver, but you cannot have a UMDF lower level filter.Anonymous
October 13, 2006
I'm doing some firmware and hardware design needs to create drivers for windows.Anonymous
March 28, 2008
trying to make my computer work betterAnonymous
April 01, 2008
You say that UMDF can be use for software-only driver, e.g. virtual ports. I assume that this includes also virtual COM ports. But how can I handle the unsupported IRPs, e.g. IRP_MJ_FLUSH_FILE_BUFFERS?Anonymous
October 06, 2008
Can I write a User-Mode driver to control copying some files (located by Database) to terminal devices like USB, DVD,...?Anonymous
October 16, 2008
The comment has been removedAnonymous
October 16, 2008
i forgot i trying to do a umdf driver for a USB bulk or isochronous transfer