Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results
The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.
Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/
Upcoming OSR Seminars | ||
---|---|---|
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead! | ||
Kernel Debugging | 9-13 Sept 2024 | Live, Online |
Developing Minifilters | 15-19 July 2024 | Live, Online |
Internals & Software Drivers | 11-15 Mar 2024 | Live, Online |
Writing WDF Drivers | 20-24 May 2024 | Live, Online |
Comments
OK, I think I am well on my way to getting this thing ported.
Thanks everyone.
-- Jamey
Bent from my phone
________________________________
From: [email protected] on behalf of [email protected]
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:
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
Peter
OSR
@OSRDrivers
Peter Viscarola
OSR
@OSRDrivers
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.
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?
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
Peter Viscarola
OSR
@OSRDrivers
* Bob
? Bob Ammerman
? [email protected]
? 716.864.8337
138 Liston St
Buffalo, NY 14223
www.ramsystems.biz
-----Original Message-----
From: [email protected] <[email protected]> On Behalf Of [email protected]
Sent: Wednesday, March 14, 2018 9:48 AM
To: Windows System Software Devs Interest List <[email protected]>
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://www.osronline.com/showlists.cfm?list=ntdev>
MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at <http://www.osr.com/seminars>
To unsubscribe, visit the List Server section of OSR Online at <http://www.osronline.com/page.cfm?name=ListServer>
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, [email protected] 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: showlists.cfm?list=ntdev>
>
> 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://www.osronline.com/page.cfm?name=ListServer>
>
d
From: [email protected] On Behalf Of [email protected]
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, [email protected] > 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: >
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
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;
</quote>
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
Peter Viscarola
OSR
@OSRDrivers
WDM code will live on.
Jan
-----Original Message-----
From: [email protected] <[email protected]> On Behalf Of [email protected]
Sent: Wednesday, March 14, 2018 6:48 AM
To: Windows System Software Devs Interest List <[email protected]>
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://www.osronline.com/showlists.cfm?list=ntdev>
MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at <http://www.osr.com/seminars>
To unsubscribe, visit the List Server section of OSR Online at <http://www.osronline.com/page.cfm?name=ListServer>
Last I knew, you
could NOT get static verifier to work on a three way hybrid driver
</quote>
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).
<quote>
The IRP building and QueryInterface were almost exactly from a WDM sample.
</quote>
In other words, they were probably outdated, broken, and buggy... right?
Sorry, dude... Couldn't resist ;-)
Peter
OSR
@OSRDrivers
Peter Viscarola
OSR
@OSRDrivers
"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: [email protected] <[email protected]> On Behalf Of [email protected]
Sent: Wednesday, March 14, 2018 1:59 PM
To: Windows System Software Devs Interest List <[email protected]>
Subject: RE:[ntdev] Help Stamp Out Sensless WDM Usage
<quote>
Last I knew, you
could NOT get static verifier to work on a three way hybrid driver </quote>
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).
<quote>
The IRP building and QueryInterface were almost exactly from a WDM sample.
</quote>
In other words, they were probably outdated, broken, and buggy... right?
Sorry, dude... Couldn't resist ;-)
Peter
OSR
@OSRDrivers
---
NTDEV is sponsored by OSR
Visit the list online at: <http://www.osronline.com/showlists.cfm?list=ntdev>
MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at <http://www.osr.com/seminars>
To unsubscribe, visit the List Server section of OSR Online at <http://www.osronline.com/page.cfm?name=ListServer>
"The driver does not combine driver models (for example, KMDF with WDM, or KMDF
and NDIS)."
</quote>
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 Viscarola
OSR
@OSRDrivers
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).
On Tue, Mar 20, 2018 at 11:15 PM, [email protected]
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: showlists.cfm?list=ntdev>
>
> 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://www.osronline.com/page.cfm?name=ListServer>
>
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
Peter Viscarola
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.
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, [email protected]
Providenza & Boekelheide, Inc.
Tim Roberts, [email protected]
Software Wizard Emeritus