I’m trying to investigate a crash dump in a driver that was written with DMF. Do you know if there’s a WinDbg extension to retrieve info on DMF objects, like DMFMODULE, for instance?
I doubt there is a windbg extension, but the source code is available on github.
“Good luck with that”… DMF? Not a fan.
@“Peter_Viscarola_(OSR)” I’m not a fan either, but I need to debug a crash in it.
But from the curiosity, what did DMF do to you? My main beef with it is that it’s poorly documented and no one outside of MSFT seems to care about it. (Kinda like what you see with this post.)
what did DMF do to you
It didn’t DO anything to me. In fact, I consider several of the folks who work(ed) on it my friends. At least one of the guys formerly worked on the WDF team, so they DO generally know what they’re doing.
But, DMF:
- Is not supported by MSFT, or by anybody
- Is large and not particularly efficient
- Is generally undocumented
- Strongly encourages you to adopt a different paradigm than just WDF (yes, you can use little pieces of DMF without adopting the whole DMF model, but that’s really not a great idea)
- Is not widely used or understood outside of one team at MSFT, and therefore is an inherent maintenance problem
The Surface team has historically been the only group within MSFT that writes a significant number of Windows drivers. They’re the ones who invented DMF. They have an excellent group of devs and testers, who are well-steeped in the use and maintenance of DMF. DMF driver development is “baked into” their culture and their group processes. They use it every day. On the Surface team, if there’s something in DMF is that’s broken, that doesn’t suit your requirements, or that you don’t understand, you just need to talk to a person two offices away. DMF makes sense for them.
For other folks, DMF is just a large, obscure, undocumented, unsupported, strange, class library that builds on WDF. One more thing for devs and maintainers to have to struggle to fix. I see absolutely no advantages, and multiple disadvantages, to its use among 3rd party driver devs.
I see. What’s also confusing are those acronyms. WDM, WDF (KMDF, UMDF), DMF. Especially for beginners. “Ef-what?”
They should’ve stuck with WDF. At least it was a step up over WDM. Btw, you probably meant DMF in that ordered list - “But, WDF”.
Hi,
This reply is from the team at Microsoft that supports/maintains DMF.
A debugger extension exists but was not released. It is not clear to me why it was not released along with DMF. There was some kind of issue related to releasing it. I will investigate that and try to see if we can add the source code for the debugger extension to the repository.
A DMFMODULE is just a WDFMEMORY that represents a DMF_OBJECT structure. To see it, use the following commands in Windbg:
!wdfmemory <DMFMODULE>
Then, given the buffer address, enter:
dt <buffer address> DMF_OBJECT
Please send queries/feedback about DMF to dmf-feedback@microsoft.com We respond to this alias within one business day in most cases.
As far as the feedback from Peter and others…Thank you for the feedback. We believe the documentation provided is relatively complete, but we are planning a mild documentation refresh in the near future specifically for the Modules. If there is something that is lacking or wrong in the documentation, please let us know. We want to fix it.
As for the feedback about DMF for external users: We have worked closely with external users who needed updates to either correct issues or add features they needed. All those corrections/features have been integrated into the released version of DMF (with their permission, of course). Of course, WDF is write-only (as it should be). However, DMF is designed to be read-write and we believe (as do many users of DMF) that DMF fulfills a specific but important purpose in the Windows device driver ecosystem. Over the past years, there as been a steady stream of releases and we plan to continue releases as new features are added and bugs are fixed.
Generally, we do not monitor this board, but we will try to do so more than we have been in the future. We respond to issues posted on Github and at dmf-feedback@microsoft.com usually within one business day.
@hamzamust thank you for following up on this. It’s nice to know that there’s an email to get hold of the DMF team.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.