Help Stamp Out Sensless WDM Usage

Ducking auto-correct, I swear. I’ll go back and edit that post. Oh, wait…

Peter
OSR
@OSRDrivers

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 :slight_smile:

Mark Roddy

On Fri, Mar 9, 2018 at 10:50 AM, xxxxx@osr.com
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:> showlists.cfm?list=ntdev>
>
> 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://www.osronline.com/page.cfm?name=ListServer&gt;
></http:></http:>

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.com <
xxxxx@lists.osr.com> 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 :slight_smile:

Mark Roddy

On Fri, Mar 9, 2018 at 10:50 AM, xxxxx@osr.com
> 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:>> lists.cfm?list=ntdev>
>>
>> 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://www.osronline.com/page.cfm?name=ListServer&gt;
>>
>
> — 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:>

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 :slight_smile:

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>

On Sat, Mar 10, 2018 at 6:03 PM, xxxxx@pmatrix.com > wrote:

>
>
>
> 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.
>
>
>
>
>
Um, you mean like this: Choosing a driver model
https:

Mark Roddy</https:>

Peter wrote: “When would someone HAVE to write a WDM driver, exactly?”

Kernel Service drivers. I have had to write a few in my time, in fact wrote one last year.

I left software development about 12 years ago (before WDF was a thing). Since I have returned, I’ve written one new driver that was a virtual storport miniport. These beasts live somewhere between a WDM and a miniport.

Recently I have been working on a older WDM driver written by someone else about 10 years ago. I have been considering the idea of porting the driver to a WDF/KMDF driver, but have put that on the back burner because of the demands to get code shipped.

However, after reading Peter’s post, I have decided to move the port to the foreground. How difficult can it be; right?

After reading the documentation, I see that if you want to receive PNP notifications, you must be a WDM driver. In the driver I am working on, it filters IRP_MJ_PNP in order to detect special files on the volume (this is a volume filter driver, not an FS volume filter). This is done to maintain the power pageable bit while the filter is active.

Does this requirement prevent me from porting to WDF/KMDF?

– Jamey

BTW: When I reply via email, the emails get lost. I sent this same post via email, and the email is nowhere to be found, not even in my outbox. Strange. So I have to come here to the website to post. If this gets posted twice, I apologize.

>>When would someone HAVE to write a WDM driver, exactly

Kernel Service drivers.

Yes, absolutely agree that writing Kernel Services using WDM is both entirely appropriate and a Best Practice. I *thought* I said that in my long initial rant, but perhaps it was somewhere else that I ranted this carve-out.

But, in any case, agreed: Kernel Services should be WDM (though they do not HAVE to be WDM).

Peter
OSR
@OSRDrivers

Peter,

You did say it, and for a simple kernel service I totally agree. I
recently did rewrite one kernel service driver to KMDF, the original WDM had
something like 20 cancel safe queues to do weird things. Moving it to KMDF
queues made the code so much nicer!

Don Burn
Windows Driver Consulting
Website: http://www.windrvr.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Monday, March 12, 2018 11:55 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Help Stamp Out Sensless WDM Usage

>>When would someone HAVE to write a WDM driver, exactly

>Kernel Service drivers.

Yes, absolutely agree that writing Kernel Services using WDM is both
entirely appropriate and a Best Practice. I thought I said that in my
long initial rant, but perhaps it was somewhere else that I ranted this
carve-out.

But, in any case, agreed: Kernel Services should be WDM (though they do not
HAVE to be WDM).

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:</http:></http:></http:>

Warning: Thread Drift Ahead

No! You can still filter and receive these. WdfDeviceInitAssignWdmIrpPreprocessCallback is your friend.

You are aware that there’s WdfDeviceSetSpecialFileSupport ?

Peter
OSR
@OSRDrivers

xxxxx@osr.com wrote:

No! You can still filter and receive these. WdfDeviceInitAssignWdmIrpPreprocessCallback is your friend.

I suspect the author of the original quote really meant “at least a WDM
driver”.  All KMDF drivers are also WDM drivers.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Peter,

Does KMDF support normal flag handling for filter drivers? I thought
it did, so since the original question was on a filter, this should be let
the framework do it.

Don Burn
Windows Driver Consulting
Website: http://www.windrvr.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Monday, March 12, 2018 12:01 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Help Stamp Out Sensless WDM Usage

Warning: Thread Drift Ahead



No! You can still filter and receive these.
WdfDeviceInitAssignWdmIrpPreprocessCallback is your friend.



You are aware that there’s WdfDeviceSetSpecialFileSupport ?

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:</http:></http:></http:>

Peter, no. I just started digging into the documentation last night. I have zero WDF/KMDF experience. It will take me a few days to come up to speed.

I’ve run into my first issue :slight_smile:

In the WDM driver, I would check device characteristics to see if the device was something we were not interested in filtering. Here is a snippet of WDM code:

NTSTATUS FilterAddDevice(In PDRIVER_OBJECT Driver,
In PDEVICE_OBJECT PhysicalDevice) {
if (FlagOn(PhysicalDevice->Characteristics, FILE_REMOVABLE_MEDIA) ||
FlagOn(PhysicalDevice->Characteristics, FILE_READ_ONLY_DEVICE) ||
FlagOn(PhysicalDevice->Characteristics, FILE_READ_ONLY_VOLUME)) {
// We are not interested in removable media. Exit with nothing to do.
return STATUS_SUCCESS;
}

This would skip filtering read-only and removable devices. In WDF, I cannot get access to the lower device object to get the characteristics. I assume WdfDeviceCreate() attaches to the lower device by me having called WdfFdoInitSetFilter() prior to calling WdfDeviceCreate().

So, let’s say I have called WdfDeviceCreate(), I check the characteristics after calling WdfGetDeviceCharacteristsic(), and determine I really do not want to filter this device.

How do I go about detaching from the lower device before exiting EvtDevicedd() function? I don’t want to have a null filter sitting there just passing data along; do I?

Maybe I am missing something. I am reading the documentation while trying to do the port.

– Jamey

WdfFdoInitWdmGetPhysicalDevice and you have the same code as below without creating a WDFDEVICE

-----Original Message-----
From: xxxxx@lists.osr.com On Behalf Of xxxxx@gmail.com
Sent: Monday, March 12, 2018 3:09 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Help Stamp Out Sensless WDM Usage

I’ve run into my first issue :slight_smile:

In the WDM driver, I would check device characteristics to see if the device was something we were not interested in filtering. Here is a snippet of WDM code:

NTSTATUS FilterAddDevice(In PDRIVER_OBJECT Driver,
In PDEVICE_OBJECT PhysicalDevice) {
if (FlagOn(PhysicalDevice->Characteristics, FILE_REMOVABLE_MEDIA) ||
FlagOn(PhysicalDevice->Characteristics, FILE_READ_ONLY_DEVICE) ||
FlagOn(PhysicalDevice->Characteristics, FILE_READ_ONLY_VOLUME)) {
// We are not interested in removable media. Exit with nothing to do.
return STATUS_SUCCESS;
}

This would skip filtering read-only and removable devices. In WDF, I cannot get access to the lower device object to get the characteristics. I assume WdfDeviceCreate() attaches to the lower device by me having called WdfFdoInitSetFilter() prior to calling WdfDeviceCreate().

So, let’s say I have called WdfDeviceCreate(), I check the characteristics after calling WdfGetDeviceCharacteristsic(), and determine I really do not want to filter this device.

How do I go about detaching from the lower device before exiting EvtDevicedd() function? I don’t want to have a null filter sitting there just passing data along; do I?

Maybe I am missing something. I am reading the documentation while trying to do the port.

– Jamey


NTDEV is sponsored by OSR

Visit the list online at: https:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at https:

To unsubscribe, visit the List Server section of OSR Online at https:</https:></https:></https:>

Thanks! I hadn’t found that function yet.

One more thing: When I call WdfFoInitSetFilter(), does it also propagate the device type? In my WDM code, I had to propagate the device type to the filter device object by hand.
The WDK says it “propagates flags & characteristics”. However, it seems reasonable to expect the device type to be propagated in the context of a filter driver. In the WDK sample kbdfilter driver, it sets the device type as follows:

WdfDeviceInitSetDeviceType(DeviceInit, FILE_DEVICE_KEYBOARD);

Otherwise, I have to have code like this:

// Get the device property class GUID.
ULONG ResultLength = 0;
WCHAR PropertyBuffer[MAX_UNICODE_STACK_BUFFER_LENGTH];
ULONG BufferLength = MAX_UNICODE_STACK_BUFFER_LENGTH;
if (NT_ERROR(WdfFdoInitQueryProperty(DeviceInit, DevicePropertyClassGuid,
BufferLength, PropertyBuffer, &ResultLength))) {
// We cannot attach to this device, so do nothing.
return STATUS_SUCCESS;
}

// Double check that someone has not tried to load this driver
// on an unsupported device type.
UNICODE_STRING DevGuid;
RtlInitUnicodeString(&DevGuid, PropertyBuffer);
if (RtlEqualUnicodeString(&DevGuid, &g_VolumeSnapshotGUID, TRUE)) {
// If this is a snapshot, we flag it as a virtual disk.
WdfDeviceInitSetDeviceType(DeviceInit, FILE_DEVICE_VIRTUAL_DISK);
}
else if (RtlEqualUnicodeString(&DevGuid, &g_VolumeGUID, TRUE)) {
// If this is a volume, we flag it as a disk.
WdfDeviceInitSetDeviceType(DeviceInit, FILE_DEVICE_DISK);
}
else {
// Unsupported device type, so do nothing.
return STATUS_SUCCESS;
}

– Jamey

Nevermind, using your advice above, I can make a single call to set the device type after passing the string tests.

OK, I think I am well on my way to getting this thing ported.

Thanks everyone.

– Jamey

SetFilter will propagate the device type iirc. Wdf is open sourced, you can see for yourself.

Bent from my phone


From: xxxxx@lists.osr.com on behalf of xxxxx@gmail.com
Sent: Monday, March 12, 2018 3:36:22 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Help Stamp Out Sensless WDM Usage

Nevermind, using your advice above, I can make a single call to set the device type after passing the string tests.

OK, I think I am well on my way to getting this thing ported.

Thanks everyone.

– Jamey


NTDEV is sponsored by OSR

Visit the list online at: https:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at https:

To unsubscribe, visit the List Server section of OSR Online at https:</https:></https:></https:>

Thread drift, folks… back on topic, if we can? Mr. Kirby… start a new thread.

Peter
OSR
@OSRDrivers

Peter wrote: "Kernel Services should be WDM "

So I was looking for documentation on a dummy inf for a kernel service driver, just to get it signed, and all I could find was documentation for wdf sections in a dummy inf. I had to go back to the 7600 DDK and find a sample inf that didnt have a manufacturers section to use as a template.

So in this instance we need the WDM documentation preserved. :slight_smile:

I understand your frustration Peter, I too have started using WDF, on your recommendation, and my initial nausea soon passed as I realised it really is very robust and simple.

But I think, like using MFC in preference to the Win32 API, that it is a wrapper on a base API, and it does no harm to be aware of that base API, and to have it documented. The issue is to use the wrapper in preference because it is so damn easy to throw stuff together.

Perhaps that should be your focus?