Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results


More Info on Driver Writing and Debugging

The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.

Check out The OSR Learning Library at:

Before Posting...

Please check out the Community Guidelines in the Announcements and Administration Category.

UMDF 1.0 to 2.0 mapping?

Michal_VodickaMichal_Vodicka Member - All Emails Posts: 109

I'm porting my old UMDF 1.0 USB driver to UMDF 2.0. I wonder if there is a mapping of UMDF 1.0 COM interfaces/methods to UMDF 2.0 functions. It'd be really helpful, without it this task is a bit tedious.

I expected it exists and tried to find it but no success. I hope it is just my inability to use Google ;-)


  • craig_howardcraig_howard Member Posts: 66

    Extraordinarily painful ... you're likely better off rewriting it in UMDF 2.0 in all seriousness. Beyond the "fun" of COM, there are enough functions that don't quite completely map to UMDF 2.0 land that you'll spend more time working around those rough edges than if you simply sketch out what the driver is supposed to do and write that in UMDF 2.0

  • Michal_VodickaMichal_Vodicka Member - All Emails Posts: 109

    I have it already done. Yes, it wasn't straightforward and I'm still debugging some issues caused by differences but still better than rewriting from scratch. The driver logic remained the same.

    When I compare the result with the original code I find UMDF 2.0 code shorter, easier to read and more logical. Just all functions have one more parameter, the device context. Seems to me UMDF 1.0 was step out which shouldn't be done.

  • Doron_HolanDoron_Holan Member - All Emails Posts: 10,600

    In hindsight, I completely agree. At the time, there was reason to believe that COM was the durable abstraction we should use if we wanted to enable app developers to be comfortable writing drivers (since they already lived and breathed COM). Now we know that UMDF1.0 developers were almost exclusively KM developers who moved up into UM and COM was far from ideal for that audience. That's is one of the strong reasons why UMDF2 is code compatible with KMDF, the dev pool for both is the same.

    Another reason COM was in UMDF1.0 was that to a small degree, we shipped our org. There were separate UMDF and KMDF dev teams reporting to the same manager and each team was hyper focused on their own environment. We shared code and patterns, but operated somewhat independently. The passion for COM came from the UMDF team, the KMDF team stated its objections, but in the end, the UMDF team owned the decision.

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,493

    the KMDF team stated its objections, but in the end, the UMDF team owned the decision.

    That's a very candid explanation that matches exactly with my personal recollection. IIRC, the architect who owned the I/O Subsystem at the time weighed in heavily on the side of COM, as well. /rolls eyes

    The UMDF team's primary misunderstanding was the thought "user mode devs" would write UMDF drivers, and "all user mode devs" know COM.

    In fact, it's not "user mode devs" who write drivers. It's mostly device people who write drivers. And there's little chance that those folks will know COM.

    The genesis of UMDF was a big departure from that of KMDF. Almost all the critical decisions about KMDF development were discuss by the MSFT team with a third party driver devs before a final decision was made. I'm not saying the MSFT blindly did whatever the third parties wanted. I'm just saying they were frequently consulted. In MY mind, this collaboration stands as one of the great historical milestones of KMDF. There's rarely been collaboration like, before or since.


    Peter Viscarola

  • Doron_HolanDoron_Holan Member - All Emails Posts: 10,600

    Also, UMDF was incubated in the Windows Media Player team to support USB media devices. That incubation was entirely COM based and influenced the project's API direction

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,970

    It's all about what you're used to. I started my first UMDF driver this month (a virtual HID device with a rather complicated report descriptor). I couldn't get it to stay loaded, and it wasn't clear why. In about 15 minutes, I rebuilt it as a KMDF driver, where I'm very comfortable with the tools. That finally got me an error that pointed out a typo in my report descriptor. I'll now go back to UMDF because I need to talk to a user-mode DLL from the client, but it was a really good example of how tight the UMDF2/KMDF matching is. And it's nice to know that switching is so easy.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • Michal_VodickaMichal_Vodicka Member - All Emails Posts: 109

    Doron, thanks for the background. It happens, I guess all of us made decisions which are suboptimal at least from hindsight.

    Still it would be nice to at least add links to original UMDF 1.0 docs to appropriate UMDF 2.0 pages. I made several funny mistakes because haven't found the right alternative on the first try. OTOH I'm not sure if is has use now, maybe most of UMDF 1.0 drivers were already rewritten to 2.0.

    BTW, I wrote this driver at 2009 and it was used all the time by different companies because of acquissions and mergers. The only reason to rewrite it now was AoAc/DFx requirements which need UMDF 2.0. I joined current owner recently without knowing it and it ended this way. I was going to port my 12 years old code :)

  • Michal_VodickaMichal_Vodicka Member - All Emails Posts: 109
    edited May 20

    Tim, yes, I like KMDF/UMDF matching a lot. As for the tools it is even easier to debug UMDF driver, you only need to know how. My driver also couldn't stay loaded on the first try, traces didn't work for unknown reason so I had to think what to do. Finally it was easy, a loop in DriverEntry, attach process from VS, break the loop manually and find the problem as in application (the driver process didn't have rights to access registry where we have traces configuration).

    The best is you can do it locally as I always did (where is my SoftICE... :)) but with UMDF it is safer.

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,493
    edited May 21

    it's nice to know that switching is so easy.

    Absolutely. I really wish it was easier. I have long fantasized about a setting in the driver properties dialog for user mode vs kernel mode.

    And, yes... I realize that some of the APIs differ slightly. But wouldn't it be cool... and EVEN EASIER... if the vast majority of the code would "just work"... Like why shouldn't you be able to call WdfDeviceMapIoSpace in kernel mode? Ah, to dream...

    It's all about what you're used to.

    This, right here, exactly. Every time I personally undertake to write something "real" in UMDF, I always wind-up switching to KMDF. .. because I've been writing kernel-mode driver code "lo these many years" and it's reasonably efficient for me to attack it that way -- But I totally acknowledge that's a limitation of my skill set and not an advantage.

    I'd love to have a serious reason to do something UMDF.

    Peter Viscarola

  • Michal_VodickaMichal_Vodicka Member - All Emails Posts: 109

    What can be done in user mode should be done in user mode. Isn't it a serious reason for you? I thought you were proposing it in the past but maybe my memory isn't correct.

    For me it is although I like kernel and low level programming. Most of my work in past years was some firmware, bare metal or some RTOS.

    This driver is biometric and it is no brainer. The driver itself is just a wrapper over big biometric library. Porting it to kernel mode is probably possible but not easy, memory allocations and stack usage. But mainly, code robustness. It was written by good developers but not driver ones. Code is robust but not paranoid. For example, they wrote:

    ASSERT(Parameter != NULL);
    *Parameter = ...

    whereas I write

    if (VERIFY(Parameter != NULL)) {
       *Parameter = ...

    The former causes BSOD in kernel with NULL parameter whereas the latter just leads to a red line in DebugView and forces me to fix it. In user mode the former crashes the driver proces which also isn't good but occasional loss of functionality is much better than BSOD. It really happened in my new driver as I made a mistake and called the library with NULL parameter in some scenario. Who knows how many such things are there? Thanks for UMDF :)

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,493
    edited May 22

    What can be done in user mode should be done in user mode.

    Oh, I absolutely agree.

    Isn't it a serious reason for you?

    Yes, but by itself not sufficient. The other part of “serious reason” that I’ve be lacking is a paying project that lends itself to being done in user mode and has a reason to live there, other than “it’s possible, but not optimal.” Given the types of work we tend to do here, that’s not super likely to come along. It’s rare that we get so write a driver for an ordinary USB device (for example). Though I’m open to the idea...

    I thought you were proposing it in the past but maybe my memory isn't correct.

    Oh, I’m all in favor of UMDF 2. No question.


    Peter Viscarola

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Developing Minifilters 24 May 2021 Live, Online
Writing WDF Drivers 14 June 2021 Live, Online
Internals & Software Drivers 27 September 2021 Live, Online
Kernel Debugging 15 November 2021 Live, Online