non-filter driver working on behalf of filter driver

Hi all,

I’m seeing lots of strange leaks and verifier errors and I’m wondering if it’s due to my architecture.

I have two filter drivers in the stack, one near the top and one near the bottom.
The drivers are setup very similarly and use a lot of the same code to do their tasks, however they are totally unaware of each other and not reliant on each other to do their work.

To help maintainability, I moved a lot of the shared code into a static library, however the filters also had identical lists of data which they were both using. This meant that when setting up these lists (from user mode) I was sending the same info to both filters so they could both have their own separate copies of what was effectively identical information (users, paths, etc)

To avoid this I developed a third legacy style driver and built it as a kernel mode dll. I moved all the shared code in this KM dll and exported all the APIs I needed. I also put the shared data and linked lists that I was holding two copies of in each filter into this one driver, and I had the two filters query this driver whenever they wanted access to this info. I finally severed the user mode comms links from the two filters and set up this KM dll driver to handle the user mode comms via IOCTLs. Th

Everything seems to work well, however verifier is throwing quite a few errors. Every time I unload the drivers I’m getting leaked file objects and I’m also seeing occasional errors on releasing FLT objects with verifier stating that the objects aren’t owned by the filter.

The kernel mode dll is making lots of Flt calls on behalf of the two filter drivers, using their FLT_FILTER and FLT_INSTANCE values to do its work. I’ve been hunting for these leaks for quite a while but can’t see any obvious errors in the code. Can these errors be due to the fact that a non-filter driver is making the calls into the fltmgr? I can’t see why that would be the case, it’s obviously running in the same address space, and has the required data from the two filters to act on their behalf, but maybe I’m overlooking something here.

Thanks in advance,
Ged.

I have seen something like this when doing this kind of scenario:
In the create routine for example trigger an LPC call from a kernel worker
thread into the user requesting some data needed for a file.

In order to make things easier in UM I use ObOpenObjectByPointer while
attached to the user process from the system thread so the user has now a
handle to that file ( avoids UM having to call CreateFile this way ) and
leave this worker thread to complete async, meaning the initial
(POST)create I let go if the UM does not respond in a timely fashion (
timeout period )

Verifier does not complain throughout, but upon unload it shows some
invalid ( already closed ) file objects as being leaked when in reality
there are no references or handles to them.
Maybe you have something similar.

If I let the unload go ( by specifying ignore to the assert in the debugger
) all unloads well with 0 resources being there.

Good luck,

Gabriel

On Sep 22, 2015 18:44, “Ged Murphy” wrote:

> Hi all,
>
> I’m seeing lots of strange leaks and verifier errors and I’m wondering if
> it’s due to my architecture.
>
> I have two filter drivers in the stack, one near the top and one near the
> bottom.
> The drivers are setup very similarly and use a lot of the same code to do
> their tasks, however they are totally unaware of each other and not reliant
> on each other to do their work.
>
> To help maintainability, I moved a lot of the shared code into a static
> library, however the filters also had identical lists of data which they
> were both using. This meant that when setting up these lists (from user
> mode) I was sending the same info to both filters so they could both have
> their own separate copies of what was effectively identical information
> (users, paths, etc)
>
> To avoid this I developed a third legacy style driver and built it as a
> kernel mode dll. I moved all the shared code in this KM dll and exported
> all the APIs I needed. I also put the shared data and linked lists that I
> was holding two copies of in each filter into this one driver, and I had
> the two filters query this driver whenever they wanted access to this info.
> I finally severed the user mode comms links from the two filters and set up
> this KM dll driver to handle the user mode comms via IOCTLs. Th
>
> Everything seems to work well, however verifier is throwing quite a few
> errors. Every time I unload the drivers I’m getting leaked file objects and
> I’m also seeing occasional errors on releasing FLT objects with verifier
> stating that the objects aren’t owned by the filter.
>
> The kernel mode dll is making lots of Flt calls on behalf of the two
> filter drivers, using their FLT_FILTER and FLT_INSTANCE values to do its
> work. I’ve been hunting for these leaks for quite a while but can’t see any
> obvious errors in the code. Can these errors be due to the fact that a
> non-filter driver is making the calls into the fltmgr? I can’t see why that
> would be the case, it’s obviously running in the same address space, and
> has the required data from the two filters to act on their behalf, but
> maybe I’m overlooking something here.
>
> Thanks in advance,
> Ged.
>
>
>
>
> —
> NTFSD is sponsored by OSR
>
> OSR is hiring!! Info at http://www.osr.com/careers
>
> For our schedule of debugging and file system seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

Filter Manager Verifier uses the return address to determine which filter a
call is coming from in cases where the filter isn’t specified as a
parameter. This can throw an erroneous Verifier error if, for example, you
called FltCreateFile from FilterA and then FltClose from a DLL that is
external to the filter. The return address to the FltClose won’t map back to
the original filter, so it looks like a leak on unload.

It’s annoying, but if you want to avoid the Verifier failure you have the
DLL call back into the filter and have *it* call FltClose.

-scott
OSR
@OSRDrivers

“Ged Murphy” wrote in message news:xxxxx@ntfsd…

Hi all,

I’m seeing lots of strange leaks and verifier errors and I’m wondering if
it’s due to my architecture.

I have two filter drivers in the stack, one near the top and one near the
bottom.
The drivers are setup very similarly and use a lot of the same code to do
their tasks, however they are totally unaware of each other and not reliant
on each other to do their work.

To help maintainability, I moved a lot of the shared code into a static
library, however the filters also had identical lists of data which they
were both using. This meant that when setting up these lists (from user
mode) I was sending the same info to both filters so they could both have
their own separate copies of what was effectively identical information
(users, paths, etc)

To avoid this I developed a third legacy style driver and built it as a
kernel mode dll. I moved all the shared code in this KM dll and exported all
the APIs I needed. I also put the shared data and linked lists that I was
holding two copies of in each filter into this one driver, and I had the two
filters query this driver whenever they wanted access to this info. I
finally severed the user mode comms links from the two filters and set up
this KM dll driver to handle the user mode comms via IOCTLs. Th

Everything seems to work well, however verifier is throwing quite a few
errors. Every time I unload the drivers I’m getting leaked file objects and
I’m also seeing occasional errors on releasing FLT objects with verifier
stating that the objects aren’t owned by the filter.

The kernel mode dll is making lots of Flt calls on behalf of the two filter
drivers, using their FLT_FILTER and FLT_INSTANCE values to do its work. I’ve
been hunting for these leaks for quite a while but can’t see any obvious
errors in the code. Can these errors be due to the fact that a non-filter
driver is making the calls into the fltmgr? I can’t see why that would be
the case, it’s obviously running in the same address space, and has the
required data from the two filters to act on their behalf, but maybe I’m
overlooking something here.

Thanks in advance,
Ged.

Yes I believe something like that happens when in the scenario I have
described above, the return address is obviously different and hence the
“leaks” but for the sake of verifier you could back into the driver to
close the handle.
But you could also hit ignore in the debugger, and proceed with the unload
and you will that there are no memory leaks.
For me it is easy to test that leak is real or not since I can dynamically
configure the driver to sent these handles to UM or not, since it is only a
performance feature not a necessary must-have and without this there are no
leaks. You might also want something like that.

Good luck,
Gabriel

On Wed, Sep 23, 2015 at 8:47 PM, Scott Noone wrote:

>


>
> Filter Manager Verifier uses the return address to determine which filter
> a call is coming from in cases where the filter isn’t specified as a
> parameter. This can throw an erroneous Verifier error if, for example, you
> called FltCreateFile from FilterA and then FltClose from a DLL that is
> external to the filter. The return address to the FltClose won’t map back
> to the original filter, so it looks like a leak on unload.
>
> It’s annoying, but if you want to avoid the Verifier failure you have the
> DLL call back into the filter and have it call FltClose.
>
> -scott
> OSR
> @OSRDrivers
>
> “Ged Murphy” wrote in message news:xxxxx@ntfsd…
>
>
> Hi all,
>
> I’m seeing lots of strange leaks and verifier errors and I’m wondering if
> it’s due to my architecture.
>
> I have two filter drivers in the stack, one near the top and one near the
> bottom.
> The drivers are setup very similarly and use a lot of the same code to do
> their tasks, however they are totally unaware of each other and not reliant
> on each other to do their work.
>
> To help maintainability, I moved a lot of the shared code into a static
> library, however the filters also had identical lists of data which they
> were both using. This meant that when setting up these lists (from user
> mode) I was sending the same info to both filters so they could both have
> their own separate copies of what was effectively identical information
> (users, paths, etc)
>
> To avoid this I developed a third legacy style driver and built it as a
> kernel mode dll. I moved all the shared code in this KM dll and exported
> all the APIs I needed. I also put the shared data and linked lists that I
> was holding two copies of in each filter into this one driver, and I had
> the two filters query this driver whenever they wanted access to this info.
> I finally severed the user mode comms links from the two filters and set up
> this KM dll driver to handle the user mode comms via IOCTLs. Th
>
> Everything seems to work well, however verifier is throwing quite a few
> errors. Every time I unload the drivers I’m getting leaked file objects and
> I’m also seeing occasional errors on releasing FLT objects with verifier
> stating that the objects aren’t owned by the filter.
>
> The kernel mode dll is making lots of Flt calls on behalf of the two
> filter drivers, using their FLT_FILTER and FLT_INSTANCE values to do its
> work. I’ve been hunting for these leaks for quite a while but can’t see any
> obvious errors in the code. Can these errors be due to the fact that a
> non-filter driver is making the calls into the fltmgr? I can’t see why that
> would be the case, it’s obviously running in the same address space, and
> has the required data from the two filters to act on their behalf, but
> maybe I’m overlooking something here.
>
> Thanks in advance,
> Ged.
>
>
>
>
> —
> NTFSD is sponsored by OSR
>
> OSR is hiring!! Info at http://www.osr.com/careers
>
> For our schedule of debugging and file system seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>


Bercea. G.

Thanks for the replies Scott and Gabriel.

Scott, what you said makes good sense, so I did as you suggested and moved all my derefs / closes into to the module that acquired it, however I’m still seeing leaks.

Instead of me wasting more time chasing these verifier warnings, I’m going to move my KM dll back to being a static lib and see if that fixes it. I guess that’s the only way I’m going to get an answer as to whether it’s my code or a verifier false positive.

Ged.

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Gabriel Bercea
Sent: 24 September 2015 12:40
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] non-filter driver working on behalf of filter driver

Yes I believe something like that happens when in the scenario I have described above, the return address is obviously different and hence the “leaks” but for the sake of verifier you could back into the driver to close the handle.

But you could also hit ignore in the debugger, and proceed with the unload and you will that there are no memory leaks.

For me it is easy to test that leak is real or not since I can dynamically configure the driver to sent these handles to UM or not, since it is only a performance feature not a necessary must-have and without this there are no leaks. You might also want something like that.

Good luck,

Gabriel

On Wed, Sep 23, 2015 at 8:47 PM, Scott Noone > wrote:



Filter Manager Verifier uses the return address to determine which filter a call is coming from in cases where the filter isn’t specified as a parameter. This can throw an erroneous Verifier error if, for example, you called FltCreateFile from FilterA and then FltClose from a DLL that is external to the filter. The return address to the FltClose won’t map back to the original filter, so it looks like a leak on unload.

It’s annoying, but if you want to avoid the Verifier failure you have the DLL call back into the filter and have it call FltClose.

-scott
OSR
@OSRDrivers

“Ged Murphy” wrote in message news:xxxxx@ntfsd…

Hi all,

I’m seeing lots of strange leaks and verifier errors and I’m wondering if it’s due to my architecture.

I have two filter drivers in the stack, one near the top and one near the bottom.
The drivers are setup very similarly and use a lot of the same code to do their tasks, however they are totally unaware of each other and not reliant on each other to do their work.

To help maintainability, I moved a lot of the shared code into a static library, however the filters also had identical lists of data which they were both using. This meant that when setting up these lists (from user mode) I was sending the same info to both filters so they could both have their own separate copies of what was effectively identical information (users, paths, etc)

To avoid this I developed a third legacy style driver and built it as a kernel mode dll. I moved all the shared code in this KM dll and exported all the APIs I needed. I also put the shared data and linked lists that I was holding two copies of in each filter into this one driver, and I had the two filters query this driver whenever they wanted access to this info. I finally severed the user mode comms links from the two filters and set up this KM dll driver to handle the user mode comms via IOCTLs. Th

Everything seems to work well, however verifier is throwing quite a few errors. Every time I unload the drivers I’m getting leaked file objects and I’m also seeing occasional errors on releasing FLT objects with verifier stating that the objects aren’t owned by the filter.

The kernel mode dll is making lots of Flt calls on behalf of the two filter drivers, using their FLT_FILTER and FLT_INSTANCE values to do its work. I’ve been hunting for these leaks for quite a while but can’t see any obvious errors in the code. Can these errors be due to the fact that a non-filter driver is making the calls into the fltmgr? I can’t see why that would be the case, it’s obviously running in the same address space, and has the required data from the two filters to act on their behalf, but maybe I’m overlooking something here.

Thanks in advance,
Ged.


NTFSD is sponsored by OSR

OSR is hiring!! Info at http://www.osr.com/careers

For our schedule of debugging and file system seminars visit: http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer



Bercea. G.

— NTFSD is sponsored by OSR OSR is hiring!! Info at http://www.osr.com/careers For our schedule of debugging and file system seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Just following up on this for the list archives.

I spent more time making sure any resource that was referenced was released in the same module and I’m pretty sure I caught everything, however I was still getting verifier issues when unloading the filter.

I therefore decided to scrap my idea of having a kernel dll as a proxy to the 2 filters and converted that project back to a static library. All verifier warnings have now disappeared so I can confirm that the Filter Manager Verifier does not work well with this kind of architecture.

To avoid data duplication I’ve now moved the shared lists and data structs into shared memory which the 2 filters know how to access. In hindsight, I should have just done this in the first place as it’s a cleaner design.

Ged.

From: Ged Murphy [mailto:xxxxx@gmail.com]
Sent: 25 September 2015 09:44
To: ‘Windows File Systems Devs Interest List’
Subject: RE: [ntfsd] non-filter driver working on behalf of filter driver

Thanks for the replies Scott and Gabriel.

Scott, what you said makes good sense, so I did as you suggested and moved all my derefs / closes into to the module that acquired it, however I’m still seeing leaks.

Instead of me wasting more time chasing these verifier warnings, I’m going to move my KM dll back to being a static lib and see if that fixes it. I guess that’s the only way I’m going to get an answer as to whether it’s my code or a verifier false positive.

Ged.

From: xxxxx@lists.osr.com mailto:xxxxx [mailto:xxxxx@lists.osr.com] On Behalf Of Gabriel Bercea
Sent: 24 September 2015 12:40
To: Windows File Systems Devs Interest List >
Subject: Re: [ntfsd] non-filter driver working on behalf of filter driver

Yes I believe something like that happens when in the scenario I have described above, the return address is obviously different and hence the “leaks” but for the sake of verifier you could back into the driver to close the handle.

But you could also hit ignore in the debugger, and proceed with the unload and you will that there are no memory leaks.

For me it is easy to test that leak is real or not since I can dynamically configure the driver to sent these handles to UM or not, since it is only a performance feature not a necessary must-have and without this there are no leaks. You might also want something like that.

Good luck,

Gabriel

On Wed, Sep 23, 2015 at 8:47 PM, Scott Noone > wrote:



Filter Manager Verifier uses the return address to determine which filter a call is coming from in cases where the filter isn’t specified as a parameter. This can throw an erroneous Verifier error if, for example, you called FltCreateFile from FilterA and then FltClose from a DLL that is external to the filter. The return address to the FltClose won’t map back to the original filter, so it looks like a leak on unload.

It’s annoying, but if you want to avoid the Verifier failure you have the DLL call back into the filter and have it call FltClose.

-scott
OSR
@OSRDrivers

“Ged Murphy” wrote in message news:xxxxx@ntfsd…

Hi all,

I’m seeing lots of strange leaks and verifier errors and I’m wondering if it’s due to my architecture.

I have two filter drivers in the stack, one near the top and one near the bottom.
The drivers are setup very similarly and use a lot of the same code to do their tasks, however they are totally unaware of each other and not reliant on each other to do their work.

To help maintainability, I moved a lot of the shared code into a static library, however the filters also had identical lists of data which they were both using. This meant that when setting up these lists (from user mode) I was sending the same info to both filters so they could both have their own separate copies of what was effectively identical information (users, paths, etc)

To avoid this I developed a third legacy style driver and built it as a kernel mode dll. I moved all the shared code in this KM dll and exported all the APIs I needed. I also put the shared data and linked lists that I was holding two copies of in each filter into this one driver, and I had the two filters query this driver whenever they wanted access to this info. I finally severed the user mode comms links from the two filters and set up this KM dll driver to handle the user mode comms via IOCTLs. Th

Everything seems to work well, however verifier is throwing quite a few errors. Every time I unload the drivers I’m getting leaked file objects and I’m also seeing occasional errors on releasing FLT objects with verifier stating that the objects aren’t owned by the filter.

The kernel mode dll is making lots of Flt calls on behalf of the two filter drivers, using their FLT_FILTER and FLT_INSTANCE values to do its work. I’ve been hunting for these leaks for quite a while but can’t see any obvious errors in the code. Can these errors be due to the fact that a non-filter driver is making the calls into the fltmgr? I can’t see why that would be the case, it’s obviously running in the same address space, and has the required data from the two filters to act on their behalf, but maybe I’m overlooking something here.

Thanks in advance,
Ged.


NTFSD is sponsored by OSR

OSR is hiring!! Info at http://www.osr.com/careers

For our schedule of debugging and file system seminars visit: http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer



Bercea. G.

— NTFSD is sponsored by OSR OSR is hiring!! Info at http://www.osr.com/careers For our schedule of debugging and file system seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer</mailto:xxxxx>