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

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

More Info on Driver Writing and Debugging


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/


Minifilter and other driver in same binary

Kei_YangKei_Yang Member Posts: 2
Hi,

I writing a Minifilter driver and I'm using the same driver to get other
system information .I would like to get some advices on how to build it...

I installed the driver using SCM and inf file to enable the Minifilter,
is that the right way?


I don`t need to have the information from the minifilter in user space
continuously and i would like enable or disable the minifilter, I had
thought 2 ways to do this:

1.- Load and unload the minifilter whatever i want without unload
the driver, is possible? I tried it but i havent had good results...

2.- Pass to kernel a flag through IOCTL to notify the Minifilter
that not send the information( although the Minifilter continue
capturing information ). I dont know if it is this righ way...

Thanks

Comments

  • Julian_NavascuesJulian_Navascues Member - All Emails Posts: 47
    Hi Alonso,

    Regardless of the design (1 or 2) I advise you to implement the unload
    properly. That will help you during development because you would be able
    to test different versions of the driver without rebooting. Also, combined
    with verifier.exe tracking yourdriver.sys and FltMgr.sys, will assure you
    certain level of QA (memory leaks, contexts leaks, etc).

    regards,

    Julián



    2016-08-12 10:43 GMT+02:00 Alonso :

    > Hi,
    >
    > I writing a Minifilter driver and I'm using the same driver to get other
    > system information .I would like to get some advices on how to build it...
    >
    > I installed the driver using SCM and inf file to enable the Minifilter, is
    > that the right way?
    >
    >
    > I don`t need to have the information from the minifilter in user space
    > continuously and i would like enable or disable the minifilter, I had
    > thought 2 ways to do this:
    >
    > 1.- Load and unload the minifilter whatever i want without unload the
    > driver, is possible? I tried it but i havent had good results...
    >
    > 2.- Pass to kernel a flag through IOCTL to notify the Minifilter that
    > not send the information( although the Minifilter continue capturing
    > information ). I dont know if it is this righ way...
    >
    > Thanks
    >
    > ---
    > NTDEV is sponsored by OSR
    >
    > Visit the list online at: lists.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&gt;
    >
  • Gabriel_BerceaGabriel_Bercea Member - All Emails Posts: 482
    Both 1 and 2 are possible.
    You can use FltUnregisterFilter. If this call does not return ( with
    verifier off ) it means you are leaking some references, handles, objects,
    etc.. Use "!stacks 2 .sys" in windbg to see this.
    To make sure you do not leak any references in the minifilter, use
    verifier.exe. It will let you know in a very direct way :)
    Other workarounds:
    You could also make you filter manually attach/detach to/from existing
    volumes. This would allow another way for your filter to process or not I/O
    but without calling FltUnregisterFilter.
    You could simply keep a list of all of your attached to instances or
    enumerate them, ( see FltEnumerateVolumes/FltEnumerateInstances) and by
    setting a flag internally ( and use synchronized access to it ) detach on
    demand from all of them and don't attach to new incoming volumes. You could
    also keep a context to an instance to see if you are currently attacked to
    it or not.

    Both options should certainly work. Try it with a simple sample filter ( a
    pass-through one for example ). Experiment with that and then see what you
    are missing from yours.

    Cheers,
    Gabriel
    www.kasardia.com
    Windows Kernel Driver Consulting

    On Fri, Aug 12, 2016 at 11:51 AM, Julián de Navascués <
    [email protected]> wrote:

    > Hi Alonso,
    >
    > Regardless of the design (1 or 2) I advise you to implement the unload
    > properly. That will help you during development because you would be able
    > to test different versions of the driver without rebooting. Also, combined
    > with verifier.exe tracking yourdriver.sys and FltMgr.sys, will assure you
    > certain level of QA (memory leaks, contexts leaks, etc).
    >
    > regards,
    >
    > Julián
    >
    >
    >
    > 2016-08-12 10:43 GMT+02:00 Alonso :
    >
    >> Hi,
    >>
    >> I writing a Minifilter driver and I'm using the same driver to get other
    >> system information .I would like to get some advices on how to build it...
    >>
    >> I installed the driver using SCM and inf file to enable the Minifilter,
    >> is that the right way?
    >>
    >>
    >> I don`t need to have the information from the minifilter in user space
    >> continuously and i would like enable or disable the minifilter, I had
    >> thought 2 ways to do this:
    >>
    >> 1.- Load and unload the minifilter whatever i want without unload the
    >> driver, is possible? I tried it but i havent had good results...
    >>
    >> 2.- Pass to kernel a flag through IOCTL to notify the Minifilter that
    >> not send the information( although the Minifilter continue capturing
    >> information ). I dont know if it is this righ way...
    >>
    >> Thanks
    >>
    >> ---
    >> NTDEV is sponsored by OSR
    >>
    >> Visit the list online at: > lists.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&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




    --
    Bercea. G.

    Cheers,
    Gabriel

  • Kei_YangKei_Yang Member Posts: 2
    Hi, thanks for your replies.

    The problem is solved, I wasnt unload the minifilter properly and the
    memory manager never called my Unload routine.

    I could load and unload the minifilter but when i wanted to unload the
    driver my unload routine never was called. That was why I doubted if my
    approach make sense...

    THANKS!!!

    El 12/08/2016 15:30, Gabriel Bercea escribió:
    > Both 1 and 2 are possible.
    > You can use FltUnregisterFilter. If this call does not return ( with
    > verifier off ) it means you are leaking some references, handles,
    > objects, etc.. Use "!stacks 2 .sys" in windbg to see this.
    > To make sure you do not leak any references in the minifilter, use
    > verifier.exe. It will let you know in a very direct way :)
    > Other workarounds:
    > You could also make you filter manually attach/detach to/from existing
    > volumes. This would allow another way for your filter to process or
    > not I/O but without calling FltUnregisterFilter.
    > You could simply keep a list of all of your attached to instances or
    > enumerate them, ( see FltEnumerateVolumes/FltEnumerateInstances) and
    > by setting a flag internally ( and use synchronized access to it )
    > detach on demand from all of them and don't attach to new incoming
    > volumes. You could also keep a context to an instance to see if you
    > are currently attacked to it or not.
    >
    > Both options should certainly work. Try it with a simple sample filter
    > ( a pass-through one for example ). Experiment with that and then see
    > what you are missing from yours.
    >
    > Cheers,
    > Gabriel
    > www.kasardia.com
    > Windows Kernel Driver Consulting
    >
    > On Fri, Aug 12, 2016 at 11:51 AM, Julián de Navascués
    > > wrote:
    >
    > Hi Alonso,
    >
    > Regardless of the design (1 or 2) I advise you to implement the
    > unload properly. That will help you during development because you
    > would be able to test different versions of the driver without
    > rebooting. Also, combined with verifier.exe tracking
    > yourdriver.sys and FltMgr.sys, will assure you certain level of QA
    > (memory leaks, contexts leaks, etc).
    >
    > regards,
    >
    > Julián
    >
    >
    >
    > 2016-08-12 10:43 GMT+02:00 Alonso >:
    >
    > Hi,
    >
    > I writing a Minifilter driver and I'm using the same driver to
    > get other system information .I would like to get some advices
    > on how to build it...
    >
    > I installed the driver using SCM and inf file to enable the
    > Minifilter, is that the right way?
    >
    >
    > I don`t need to have the information from the minifilter in
    > user space continuously and i would like enable or disable the
    > minifilter, I had thought 2 ways to do this:
    >
    > 1.- Load and unload the minifilter whatever i want without
    > unload the driver, is possible? I tried it but i havent had
    > good results...
    >
    > 2.- Pass to kernel a flag through IOCTL to notify the
    > Minifilter that not send the information( although the
    > Minifilter continue capturing information ). I dont know if it
    > is this righ way...
    >
    > Thanks
    >
    > ---
    > 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
    >
    >
    >
    >
    > --
    > Bercea. G.
    > --- 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
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
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Internals & Software Drivers 30 Nov 2020 LIVE ONLINE
Writing WDF Drivers 7 Dec 2020 LIVE ONLINE
Developing Minifilters Early 2021 LIVE ONLINE