Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

Help Stamp Out Sensless WDM Usage

2»

Comments

  • Jamey_KirbyJamey_Kirby Member - All Emails Posts: 429
    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
  • Doron_HolanDoron_Holan Member - All Emails Posts: 10,435
    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:

    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
    d
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,251
    Thread drift, folks... back on topic, if we can? Mr. Kirby... start a new thread.

    Peter
    OSR
    @OSRDrivers

    Peter Viscarola
    OSR
    @OSRDrivers

  • matt_sykesmatt_sykes Member - All Emails Posts: 270
    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. :)


    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?
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,251
    > 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_Ammerman-2Bob_Ammerman-2 Member - All Emails Posts: 56
    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 <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 <xxxxx@lists.osr.com>
    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>;
  • Jamey_KirbyJamey_Kirby Member - All Emails Posts: 429
    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...
  • Mark_RoddyMark_Roddy Member - All Emails Posts: 4,306
    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: 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>;
    >
  • Doron_HolanDoron_Holan Member - All Emails Posts: 10,435
    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.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: >

    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
    d
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,251
    <quote>
    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

  • Jan_BottorffJan_Bottorff Member - All Emails Posts: 471
    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 <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 <xxxxx@lists.osr.com>
    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>;
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,251
    <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

    Peter Viscarola
    OSR
    @OSRDrivers

  • Jan_BottorffJan_Bottorff Member - All Emails Posts: 471
    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 <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 <xxxxx@lists.osr.com>
    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>;
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,251
    <quote>
    "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

  • matt_sykesmatt_sykes Member - All Emails Posts: 270
    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).
  • Shaarang_TyagiShaarang_Tyagi Member - All Emails Posts: 13
    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: 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>;
    >
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,251
    >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

    Peter Viscarola
    OSR
    @OSRDrivers

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,002
    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.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
Developing Minifilters 29 July 2019 OSR Seminar Space
Writing WDF Drivers 23 Sept 2019 OSR Seminar Space
Kernel Debugging 21 Oct 2019 OSR Seminar Space
Internals & Software Drivers 18 Nov 2019 Dulles, VA