I think a HUGE problem for a newbie Window’s driver writer’s is figuring out he correct kind of driver to write. Other platforms tend not to have all the different flavors, they just have “a driver”. Even an experienced developer like myself sometimes has to look carefully and do a lot of digging what kind of driver is needed. For example, a network kernel winsock client that does not process IRPs would be more of a kernel service, but one that can be opened by an application (meaning it can process IRPS) would more likely be something like a root-enumerated PnP driver. If I had a kernel service that I want to control from powershell via WMI method calls, I would need to make it a driver with a do almost nothing virtual device object, just so the OS has someplace to send WMI IRPS.
Perhaps something like a decision tree in the WDK documentation on how to pick the correct kind of driver would help. A newbie will look at this thread and be clueless how a “driver”, written to the WDM API (to be avoided), is a different thing than a “kernel service” written to the WDM API (which is acceptable). This terminology is not spelled out, it’s just a set of slightly fuzzy categories that have informally formed over the years.
Another thing that could help newbie driver developers would be if the VisualStudio driver wizard knew how to make a variety of specialized class drivers, based on the latest thinking on what’s “optimal”. So then there would be no need to hunt through the samples to find something sort of similar. You would just say dear VS Wizard, make me generic storage controller driver, and it would (today) spit out a storport driver for a ramdisk or something, and tomorrow it might spit our a KMDF driver with the extra storage support.
Even though I see lots of value in miniports, and other class specific frameworks, I wonder if these just create confusion and ignorance in the long term. Windows kernel developers tend to have boundaries on their driver interface knowledge, significantly due to the miniport model. If you work for a large corporation on the same project for many years, the miniport model tends to keep you ignorant about anything outside your little world. There might be some shift occurring in this, as it seems like Microsoft is moving toward a NIC miniport being a KMDF driver, with some network specific queue ring interfaces.
Jan
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Saturday, March 10, 2018 9:52 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Help Stamp Out Sensless WDM Usage
Registry Filters, Object Manager Filters, Process Manager Filters… these are all Kernel Service, which I already mentioned are an entirely separate category of beast. WDM for this use is entirely fine.
Peter
OSR
@OSRDrivers
On Sat, Mar 10, 2018 at 10:43 AM, xxxxx@gmail.commailto:xxxxx > wrote:
registry filter drivers. I suppose you could write one using KMDF but it would add unneeded complexity rather than reducing it. Also you could write a bus filter driver using KMDF and then escape into WDM to do all the bus filtering
Mark Roddy
On Fri, Mar 9, 2018 at 10:50 AM, xxxxx@osr.commailto:xxxxx > wrote:
Good one, thank you for that. We did that here recently as well.
Rare and unsupported as well, we should note.
Peter
OSR
@OSRDrivers
—
NTDEV is sponsored by OSR
Visit the list online at: http:
MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:
To unsubscribe, visit the List Server section of OSR Online at http:
— NTDEV is sponsored by OSR Visit the list online at: MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers! Details at To unsubscribe, visit the List Server section of OSR Online at
— NTDEV is sponsored by OSR Visit the list online at: MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers! Details at To unsubscribe, visit the List Server section of OSR Online at</http:></http:></http:></mailto:xxxxx></mailto:xxxxx>