Help Stamp Out Sensless WDM Usage

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?

> Perhaps that should be your focus?

Hmmmm… Well, I didn’t say I wanted to remove WDM function documentation, did I.

The thing to keep in mind about WDF, and one very crucial thing that sets it apart from MFC (yuck!), is that KMDF allows you to “escape” from the framework directly to native system calls. This is a KEY PRECEPT of KMDF, and was something the community *insisted* on very vocally .

This ability to escape the framework to the underlying “native” API is part of the real genius of KMDF and what makes it so very powerful.

So, duh! I’m not asking to strike the description of native kernel-mode functions from the documentation. There’s a difference between the WDM DRIVER MODEL – the use of which (for everything but kernel services and a few other small niches) should be loudly decried and thoroughly discouraged – and the underlying native Windows Ke, Se, Io, Mm, Ex, Ps, Ob, and friends APIs.

What I *am* advocating is, specifically (this from my FIRST POST in this thread, qv):

  1. We need to scrub the samples to make sure there are no WDM drivers around (other
    than software only “kernel services”). If you host example on GitHub or someplace else, if it’s a WDM driver , for heavens sakes make the readme say it’s a deprecated model.

  2. We need the WDK docs to very clear say, everywhere, that people should be using WDM
    as a last resort only if they are not writing a file system or a kernel service. We should put this on every single WDM function doc page: IoXxxx, KeXxxx, etc.

  3. We should warn people to NOT start a WDM sample unless they are writing a “kernel service” – We should direct them straight to WDF.

Peter
OSR
@OSRDrivers

Not sure why you say MFC doesn’t allow ‘escape’ to underlying Windows APIs. It certainly does, and I’ve used that capability many times. MFC may not be perfect, but it really isn’t bad at all, IMHO.

* Bob

? Bob Ammerman
? xxxxx@ramsystems.biz
? 716.864.8337

138 Liston St
Buffalo, NY 14223
www.ramsystems.biz

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

> Perhaps that should be your focus?

Hmmmm… Well, I didn’t say I wanted to remove WDM function documentation, did I.

The thing to keep in mind about WDF, and one very crucial thing that sets it apart from MFC (yuck!), is that KMDF allows you to “escape” from the framework directly to native system calls. This is a KEY PRECEPT of KMDF, and was something the community insisted on very vocally .

This ability to escape the framework to the underlying “native” API is part of the real genius of KMDF and what makes it so very powerful.

So, duh! I’m not asking to strike the description of native kernel-mode functions from the documentation. There’s a difference between the WDM DRIVER MODEL – the use of which (for everything but kernel services and a few other small niches) should be loudly decried and thoroughly discouraged – and the underlying native Windows Ke, Se, Io, Mm, Ex, Ps, Ob, and friends APIs.

What I am advocating is, specifically (this from my FIRST POST in this thread, qv):

1) We need to scrub the samples to make sure there are no WDM drivers around (other than software only “kernel services”). If you host example on GitHub or someplace else, if it’s a WDM driver , for heavens sakes make the readme say it’s a deprecated model.

2) We need the WDK docs to very clear say, everywhere, that people should be using WDM as a last resort only if they are not writing a file system or a kernel service. We should put this on every single WDM function doc page: IoXxxx, KeXxxx, etc.

3) We should warn people to NOT start a WDM sample unless they are writing a “kernel service” – We should direct them straight to WDF.

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

Counter rant: WDF is kind of a cluster duck anyway. Gone are to good old days of using grep to find a function in a file. Grep WDF looking for a function; good luck. For example, grep for “WdfFdoInitSetFilter()” in the WDF source and you find yourself at a dead end; looking at a pointer to a member function. You could load the WDF source in the compiler, and search that way. But really? We’re talking about device drivers here. If you need C++ abstraction in your driver, maybe you need to rethink your design. All I wanted to do was see if WdfFdoInitSetFilter() propagated the device type field; I gave up, and just propagate it from the physical device because I have a job to do, and a deadline to meet. Maybe I am just getting too old…

C++ class hierarchy is exactly what WDM needed in order to provide a simple
api that provides default functionality that meets 90% or more of standard
wdm driver functionality. This the proliferation of many third party
wrappers around WDM that did just that.

And now this thread is going to go down this rathole.

Mark Roddy

On Wed, Mar 14, 2018 at 12:06 PM, xxxxx@gmail.com > wrote:

> Counter rant: WDF is kind of a cluster duck anyway. Gone are to good old
> days of using grep to find a function in a file. Grep WDF looking for a
> function; good luck. For example, grep for “WdfFdoInitSetFilter()” in the
> WDF source and you find yourself at a dead end; looking at a pointer to a
> member function. You could load the WDF source in the compiler, and search
> that way. But really? We’re talking about device drivers here. If you need
> C++ abstraction in your driver, maybe you need to rethink your design. All
> I wanted to do was see if WdfFdoInitSetFilter() propagated the device type
> field; I gave up, and just propagate it from the physical device because I
> have a job to do, and a deadline to meet. Maybe I am just getting too old…
>
> —
> 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:>

The classes also provide abstraction between user and kernel mode, UMDF and KMDF are built from the same source.

d

From: xxxxx@lists.osr.com On Behalf Of xxxxx@gmail.com
Sent: Wednesday, March 14, 2018 10:10 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Help Stamp Out Sensless WDM Usage

C++ class hierarchy is exactly what WDM needed in order to provide a simple api that provides default functionality that meets 90% or more of standard wdm driver functionality. This the proliferation of many third party wrappers around WDM that did just that.

And now this thread is going to go down this rathole.

Mark Roddy

On Wed, Mar 14, 2018 at 12:06 PM, xxxxx@gmail.commailto:xxxxx > wrote:
Counter rant: WDF is kind of a cluster duck anyway. Gone are to good old days of using grep to find a function in a file. Grep WDF looking for a function; good luck. For example, grep for “WdfFdoInitSetFilter()” in the WDF source and you find yourself at a dead end; looking at a pointer to a member function. You could load the WDF source in the compiler, and search that way. But really? We’re talking about device drivers here. If you need C++ abstraction in your driver, maybe you need to rethink your design. All I wanted to do was see if WdfFdoInitSetFilter() propagated the device type field; I gave up, and just propagate it from the physical device because I have a job to do, and a deadline to meet. Maybe I am just getting too old…


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

REALLY? I found THIS in the very first .CPP file listed:

_drv_maxIRQL(PASSIVE_LEVEL)
VOID
WDFEXPORT(WdfFdoInitSetFilter)(
__in
PWDF_DRIVER_GLOBALS DriverGlobals,
__in
PWDFDEVICE_INIT DeviceInit
)
{
DDI_ENTRY();

PFX_DRIVER_GLOBALS pFxDriverGlobals;

FxPointerNotNull(GetFxDriverGlobals(DriverGlobals), DeviceInit);
pFxDriverGlobals = DeviceInit->DriverGlobals;

if (!NT_SUCCESS(FxVerifierCheckIrqlLevel(pFxDriverGlobals,
PASSIVE_LEVEL))) {
return;
}
if (DeviceInit->IsNotFdoInit()) {
DoTraceLevelMessage(
pFxDriverGlobals, TRACE_LEVEL_ERROR, TRACINGDEVICE,
“Not a PWDFDEVICE_INIT for an FDO”);

FxVerifierDbgBreakPoint(pFxDriverGlobals);
return;
}

DeviceInit->Fdo.Filter = TRUE;
}

I’ve heard this complaint about the WDF sources before. But, understand, what you’re complaining about is simply your own lack of familiarity with the source code.

You expect to be able to grep the I/O Manager source code and INSTANTLY be able to figure out… say… what a simple function like IoCallDriver does? Because I don’t think that’s a reasonable thing.

The source code to (anything) is super useful. But I don’t think it’s reasonable to expect to be able to dive-in and find an answer with little/no preliminary work.

Peter
OSR
@OSRDrivers

There may be a little gotcha to wiping out all WDM sample code. Last I knew, you could NOT get static verifier to work on a three way hybrid driver. I discovered this when working on a virtual NIC miniport that used NDIS, WDF (to talk to lower layers) and WDM API calls for a few things that were impossible in WDF. It was possible to have NDIS+WDM or NDIS+WDF but not NDIS+WDF+WDM. As WDF had no way to queue directed DPCs, I had to use WDM calls, but since I could then not use WDF, I had to write a little WDM code to do the QueryInterface to the lower layer. The IRP building and QueryInterface were almost exactly from a WDM sample. Since getting the static verifier log is required for WHQL certification, it’s impossible to have a WHQL certified three way hybrid driver.

WDM code will live on.

Jan

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

> Perhaps that should be your focus?

Hmmmm… Well, I didn’t say I wanted to remove WDM function documentation, did I.

The thing to keep in mind about WDF, and one very crucial thing that sets it apart from MFC (yuck!), is that KMDF allows you to “escape” from the framework directly to native system calls. This is a KEY PRECEPT of KMDF, and was something the community insisted on very vocally .

This ability to escape the framework to the underlying “native” API is part of the real genius of KMDF and what makes it so very powerful.

So, duh! I’m not asking to strike the description of native kernel-mode functions from the documentation. There’s a difference between the WDM DRIVER MODEL – the use of which (for everything but kernel services and a few other small niches) should be loudly decried and thoroughly discouraged – and the underlying native Windows Ke, Se, Io, Mm, Ex, Ps, Ob, and friends APIs.

What I am advocating is, specifically (this from my FIRST POST in this thread, qv):

1) We need to scrub the samples to make sure there are no WDM drivers around (other than software only “kernel services”). If you host example on GitHub or someplace else, if it’s a WDM driver , for heavens sakes make the readme say it’s a deprecated model.

2) We need the WDK docs to very clear say, everywhere, that people should be using WDM as a last resort only if they are not writing a file system or a kernel service. We should put this on every single WDM function doc page: IoXxxx, KeXxxx, etc.

3) We should warn people to NOT start a WDM sample unless they are writing a “kernel service” – We should direct them straight to WDF.

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

Well, that’s just plain silly. Please tell me you reported this and they’re fixing whatever specific issues you surfaced, right? If there are bugs in SDV in certain situations, those need fixed. In the meantime, there’s Analysis_Assume

Let’s be clear: There IS no WDF driver that doesn’t include some native Windows kernel-mode API function calls. I mean, seriously: Does anybody call WdfMemoryCreate in place of calling ExAllocatePoolWithTag?? Shit, there are things you can’t even DO in WDF without calling a native Windows kernel-mode function (the most obvious example being MmMapIoSpace… (and, no… please don’t remind me about WdfDeviceMapIoSpace… you KNOW UMDF is not what I’m talking about).

In other words, they were probably outdated, broken, and buggy… right?

Sorry, dude… Couldn’t resist :wink:

Peter
OSR
@OSRDrivers

Currently, the MSFT doc page at https://docs.microsoft.com/en-us/windows-hardware/drivers/devtest/determining-if-static-driver-verifier-supports-your-driver-or-library say SDV works on drivers that meet the following requirement:

“The driver does not combine driver models (for example, KMDF with WDM, or KMDF and NDIS).”

My experience has been two way hybrid drivers work, but three way don’t. I just submitted a doc feedback request, as what is says right now does not seem correct.

Jan

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



Well, that’s just plain silly. Please tell me you reported this and they’re fixing whatever specific issues you surfaced, right? If there are bugs in SDV in certain situations, those need fixed. In the meantime, there’s Analysis_Assume

Let’s be clear: There IS no WDF driver that doesn’t include some native Windows kernel-mode API function calls. I mean, seriously: Does anybody call WdfMemoryCreate in place of calling ExAllocatePoolWithTag?? Shit, there are things you can’t even DO in WDF without calling a native Windows kernel-mode function (the most obvious example being MmMapIoSpace… (and, no… please don’t remind me about WdfDeviceMapIoSpace… you KNOW UMDF is not what I’m talking about).



In other words, they were probably outdated, broken, and buggy… right?

Sorry, dude… Couldn’t resist :wink:

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

Well THAT flies in the face of “you need to pass SDV in order to logo”… I wonder how they POSSIBLY reconcile this?

Peter
OSR
@OSRDrivers

Peter wrote: " MFC (yuck!)"

MFC is a fine thing Peter. It allows you to put together apps very quickly, and the DDE feature is very handy, much easier than getting window pointers to your controls when you need to change their state.

And you can jump out to the win32 API very simply by using the double colon to use the global namespace, or just using the function you want if it isnt part of some class (such as windows hooks).

Is MFC still used , if yes , why?

On Tue, Mar 20, 2018 at 11:15 PM, xxxxx@hotmail.com
wrote:

> Peter wrote: " MFC (yuck!)"
>
> MFC is a fine thing Peter. It allows you to put together apps very
> quickly, and the DDE feature is very handy, much easier than getting window
> pointers to your controls when you need to change their state.
>
> And you can jump out to the win32 API very simply by using the double
> colon to use the global namespace, or just using the function you want if
> it isnt part of some class (such as windows hooks).
>
>
>
> —
> 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:>

>Is MFC still used , if yes , why?

We’re using it right now. We have a client, who needs to have a system-tray app written that also does notifications. Of course, writing the app in C# would be the natural choice, but… the client has a strict rule against the use of any .Net language in their shipping code.

In fact, they wanted the user-mode code written in strict native Win32 C (*not* C++, no STL or ATL) and I had to persuade them to allow us to use C++/MFC/ATL for the sake of efficiency of development.

We don’t run into this requirement often, but it’s also not unheard of for us. Security folks tend to have very specific and strongly held positions, and we generally have learned not to argue with those who pay the bills.

And, yes. Regardless of what anybody else says, MFC sucks. I’m not going to debate this. If it didn’t suck back in 1992 when it was first introduced, it started to suck sometime between then and now. In fact, I was surprised to find that it was still supported and not officially deprecated.

What I *really* want to know is why we are talking about this on this forum.

Peter
OSR
@OSRDrivers

xxxxx@hotmail.com wrote:

Peter wrote: " MFC (yuck!)"

MFC is a fine thing Peter. It allows you to put together apps very quickly, and the DDE feature is very handy, much easier than getting window pointers to your controls when you need to change their state.

You said “DDE”, but I’m pretty sure you meant “DDX”.  DDE is a crusty
leftover that belongs in the dustbin of history.

I never understood why WTL never took over the world.  It is a far more
sensible framework than MFC, it feels much more natural in C++, and it
is significantly lighter weight.  I still use it for all of my UI and
diagnostic apps (at least, when I don’t need cross-platform, which is a
bigger and bigger consideration).

I suppose its crime was that it came out at the time Microsoft was
de-emphasizing C++ in favor of C#.


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