Help Stamp Out Sensless WDM Usage

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.