what problems stop mini-filter unregister from completing?

NTFSD
1

My mini-filter’s call to FltUnregisterFilter doesn’t complete. I assume
this is because I am not freeing some resource.

I put in debug statements and every single call to FltAllocateContext is
matched by a callback to a cleanup routine, yet a few of my context records
show up as still allocated in !poolused. I assume that the filter manager
has just not gotten around to freeing them. These are the only tagged
allocations remaining and I use only tagged allocations, so I am confident
I’m not causing any pool leaks.

So what other than pool allocations can cause the unregister to hang? Is
there a list somewhere of things that can cause this?

2

I found this list that Ken Cross provided a few months ago. Can anyone
think of anything else?

FltAllocateContext
FltGetFileNameInformation
FltGetDestinationFileNameInformation
FltGetDiskDeviceObject
FltGetDeviceObject

“Mark Hahn” wrote in message news:xxxxx@ntfsd…
> My mini-filter’s call to FltUnregisterFilter doesn’t complete. I assume
> this is because I am not freeing some resource.
>
> I put in debug statements and every single call to FltAllocateContext is
> matched by a callback to a cleanup routine, yet a few of my context
> records show up as still allocated in !poolused. I assume that the filter
> manager has just not gotten around to freeing them. These are the only
> tagged allocations remaining and I use only tagged allocations, so I am
> confident I’m not causing any pool leaks.
>
> So what other than pool allocations can cause the unregister to hang? Is
> there a list somewhere of things that can cause this?
>
>

3

Mark:

According to Neal Christiansen:

“The blocking of unload will ONLY occur if you have called Flt APIs that
return an object of some kind and then don’t release the reference on them.
We can’t block unload if you call other API’s (because we don’t know that
you called them).”

So that list should be fairly complete as far as contexts go. How about
open files (FltCreateFile and friends)? Or FltAcquirexxx? Or
FltObjectReference? Or FltEnumeratexxx? There may be more…

Ken

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark Hahn
Sent: Wednesday, June 01, 2005 4:08 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] what problems stop mini-filter unregister from
completing?

I found this list that Ken Cross provided a few months ago. Can anyone
think of anything else?

FltAllocateContext
FltGetFileNameInformation
FltGetDestinationFileNameInformation
FltGetDiskDeviceObject
FltGetDeviceObject

“Mark Hahn” wrote in message news:xxxxx@ntfsd…
> My mini-filter’s call to FltUnregisterFilter doesn’t complete. I assume
> this is because I am not freeing some resource.
>
> I put in debug statements and every single call to FltAllocateContext is
> matched by a callback to a cleanup routine, yet a few of my context
> records show up as still allocated in !poolused. I assume that the filter

> manager has just not gotten around to freeing them. These are the only
> tagged allocations remaining and I use only tagged allocations, so I am
> confident I’m not causing any pool leaks.
>
> So what other than pool allocations can cause the unregister to hang? Is
> there a list somewhere of things that can cause this?
>
>

—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@comcast.net
To unsubscribe send a blank email to xxxxx@lists.osr.com

4

I encountered the same problem before. You need call
FltDeleteStreamHandleContext to explicitly delete contexts in cleanup or
close call backs. I am not sure if the IFSkit help is accurate or not. After
you call FltGetStreamHandleContext, FltReleaseContext does not delete the
context.

Shangwu

“Mark Hahn” wrote in message news:xxxxx@ntfsd…
> My mini-filter’s call to FltUnregisterFilter doesn’t complete. I assume
> this is because I am not freeing some resource.
>
> I put in debug statements and every single call to FltAllocateContext is
> matched by a callback to a cleanup routine, yet a few of my context
> records show up as still allocated in !poolused. I assume that the filter
> manager has just not gotten around to freeing them. These are the only
> tagged allocations remaining and I use only tagged allocations, so I am
> confident I’m not causing any pool leaks.
>
> So what other than pool allocations can cause the unregister to hang? Is
> there a list somewhere of things that can cause this?
>
>

5

I don’t think that’s correct.

FltReleaseContext releases (decrements) the reference caused by
FltGetStreamHandleContext. But you need to call FltReleaseContext again in
the cleanup to decrement the reference cause by the initial
FltAllocateContext that created the context in the first place.

Ken

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Shangwu
Sent: Wednesday, June 01, 2005 6:08 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] what problems stop mini-filter unregister from
completing?

I encountered the same problem before. You need call
FltDeleteStreamHandleContext to explicitly delete contexts in cleanup or
close call backs. I am not sure if the IFSkit help is accurate or not. After

you call FltGetStreamHandleContext, FltReleaseContext does not delete the
context.

Shangwu

“Mark Hahn” wrote in message news:xxxxx@ntfsd…
> My mini-filter’s call to FltUnregisterFilter doesn’t complete. I assume
> this is because I am not freeing some resource.
>
> I put in debug statements and every single call to FltAllocateContext is
> matched by a callback to a cleanup routine, yet a few of my context
> records show up as still allocated in !poolused. I assume that the filter

> manager has just not gotten around to freeing them. These are the only
> tagged allocations remaining and I use only tagged allocations, so I am
> confident I’m not causing any pool leaks.
>
> So what other than pool allocations can cause the unregister to hang? Is
> there a list somewhere of things that can cause this?
>
>

—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@comcast.net
To unsubscribe send a blank email to xxxxx@lists.osr.com

6

Neal said in an earlier message:

You should not maintain your own list of contexts just for the
purpose of deleting them at unload time. We do this for you
automatically and all you are doing is adding unnecessary overhead.

I tried this anyway, and it made no difference.

I have gone through every single FLT call and can find no leak. This is a
real pain in the a**.

“Shangwu” wrote in message news:xxxxx@ntfsd…
>I encountered the same problem before. You need call
>FltDeleteStreamHandleContext to explicitly delete contexts in cleanup or
>close call backs. I am not sure if the IFSkit help is accurate or not.
>After you call FltGetStreamHandleContext, FltReleaseContext does not delete
>the context.
>
> Shangwu
>
> “Mark Hahn” wrote in message news:xxxxx@ntfsd…
>> My mini-filter’s call to FltUnregisterFilter doesn’t complete. I assume
>> this is because I am not freeing some resource.
>>
>> I put in debug statements and every single call to FltAllocateContext is
>> matched by a callback to a cleanup routine, yet a few of my context
>> records show up as still allocated in !poolused. I assume that the
>> filter manager has just not gotten around to freeing them. These are the
>> only tagged allocations remaining and I use only tagged allocations, so I
>> am confident I’m not causing any pool leaks.
>>
>> So what other than pool allocations can cause the unregister to hang? Is
>> there a list somewhere of things that can cause this?
>>
>>
>
>
>

7

Some ideas:

  • Try running with the checked build filter manager. If you are leaking
    contexts it will let you know (and give you their address).
  • Try a nature study to find out how much stuff your minifilter has to do
    before it can no longer be unloaded.

/r

8

Shangwu,

It is NOT necessary for you to explicitly delete stream handle contexts
in clean/close. The system will handle this for you automatically.

Neal Christiansen
Microsoft File System Filter Group Lead
This posting is provided “AS IS” with no warranties, and confers no
Rights

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Shangwu
Sent: Wednesday, June 01, 2005 3:08 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] what problems stop mini-filter unregister from
completing?

I encountered the same problem before. You need call
FltDeleteStreamHandleContext to explicitly delete contexts in cleanup or

close call backs. I am not sure if the IFSkit help is accurate or not.
After
you call FltGetStreamHandleContext, FltReleaseContext does not delete
the
context.

Shangwu

“Mark Hahn” wrote in message news:xxxxx@ntfsd…
> My mini-filter’s call to FltUnregisterFilter doesn’t complete. I
assume
> this is because I am not freeing some resource.
>
> I put in debug statements and every single call to FltAllocateContext
is
> matched by a callback to a cleanup routine, yet a few of my context
> records show up as still allocated in !poolused. I assume that the
filter
> manager has just not gotten around to freeing them. These are the
only
> tagged allocations remaining and I use only tagged allocations, so I
am
> confident I’m not causing any pool leaks.
>
> So what other than pool allocations can cause the unregister to hang?
Is
> there a list somewhere of things that can cause this?
>
>

—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

9

Mark,

I agree with you that this is a pain. One of the things we are working
on for longhorn is that we are beefing up the minifilter verifier so it
will properly detect all leaked object references. This means if you
hang on unload it will tell you exactly what objects are improperly
referenced. We should have this support ready by the longhorn Beta 2
release.

Neal Christiansen
Microsoft File System Filter Group Lead
This posting is provided “AS IS” with no warranties, and confers no
Rights

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark Hahn
Sent: Thursday, June 02, 2005 10:08 AM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] what problems stop mini-filter unregister from
completing?

Neal said in an earlier message:

You should not maintain your own list of contexts just for the
purpose of deleting them at unload time. We do this for you
automatically and all you are doing is adding unnecessary overhead.

I tried this anyway, and it made no difference.

I have gone through every single FLT call and can find no leak. This is
a
real pain in the a**.

“Shangwu” wrote in message news:xxxxx@ntfsd…
>I encountered the same problem before. You need call
>FltDeleteStreamHandleContext to explicitly delete contexts in cleanup
or
>close call backs. I am not sure if the IFSkit help is accurate or not.
>After you call FltGetStreamHandleContext, FltReleaseContext does not
delete
>the context.
>
> Shangwu
>
> “Mark Hahn” wrote in message news:xxxxx@ntfsd…
>> My mini-filter’s call to FltUnregisterFilter doesn’t complete. I
assume
>> this is because I am not freeing some resource.
>>
>> I put in debug statements and every single call to FltAllocateContext
is
>> matched by a callback to a cleanup routine, yet a few of my context
>> records show up as still allocated in !poolused. I assume that the
>> filter manager has just not gotten around to freeing them. These are
the
>> only tagged allocations remaining and I use only tagged allocations,
so I
>> am confident I’m not causing any pool leaks.
>>
>> So what other than pool allocations can cause the unregister to hang?
Is
>> there a list somewhere of things that can cause this?
>>
>>
>
>
>

—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

10

By any chance, are you seeing this only on SRV03 SP1?

jerry

“Mark Hahn” wrote in message news:xxxxx@ntfsd…
> Neal said in an earlier message:
>
>> You should not maintain your own list of contexts just for the
>> purpose of deleting them at unload time. We do this for you
>> automatically and all you are doing is adding unnecessary overhead.
>
> I tried this anyway, and it made no difference.
>
> I have gone through every single FLT call and can find no leak. This is a
> real pain in the a**.
>
>
> “Shangwu” wrote in message news:xxxxx@ntfsd…
>>I encountered the same problem before. You need call
>>FltDeleteStreamHandleContext to explicitly delete contexts in cleanup or
>>close call backs. I am not sure if the IFSkit help is accurate or not.
>>After you call FltGetStreamHandleContext, FltReleaseContext does not
>>delete the context.
>>
>> Shangwu
>>
>> “Mark Hahn” wrote in message news:xxxxx@ntfsd…
>>> My mini-filter’s call to FltUnregisterFilter doesn’t complete. I assume
>>> this is because I am not freeing some resource.
>>>
>>> I put in debug statements and every single call to FltAllocateContext is
>>> matched by a callback to a cleanup routine, yet a few of my context
>>> records show up as still allocated in !poolused. I assume that the
>>> filter manager has just not gotten around to freeing them. These are
>>> the only tagged allocations remaining and I use only tagged allocations,
>>> so I am confident I’m not causing any pool leaks.
>>>
>>> So what other than pool allocations can cause the unregister to hang?
>>> Is there a list somewhere of things that can cause this?
>>>
>>>
>>
>>
>>
>
>
>

11

> By any chance, are you seeing this only on SRV03 SP1?

No, on XP SP2.

“Jerry Kelley” wrote in message
news:xxxxx@ntfsd…
> By any chance, are you seeing this only on SRV03 SP1?
>
> jerry
>
> “Mark Hahn” wrote in message news:xxxxx@ntfsd…
>> Neal said in an earlier message:
>>
>>> You should not maintain your own list of contexts just for the
>>> purpose of deleting them at unload time. We do this for you
>>> automatically and all you are doing is adding unnecessary overhead.
>>
>> I tried this anyway, and it made no difference.
>>
>> I have gone through every single FLT call and can find no leak. This is
>> a real pain in the a**.
>>
>>
>> “Shangwu” wrote in message news:xxxxx@ntfsd…
>>>I encountered the same problem before. You need call
>>>FltDeleteStreamHandleContext to explicitly delete contexts in cleanup or
>>>close call backs. I am not sure if the IFSkit help is accurate or not.
>>>After you call FltGetStreamHandleContext, FltReleaseContext does not
>>>delete the context.
>>>
>>> Shangwu
>>>
>>> “Mark Hahn” wrote in message news:xxxxx@ntfsd…
>>>> My mini-filter’s call to FltUnregisterFilter doesn’t complete. I
>>>> assume this is because I am not freeing some resource.
>>>>
>>>> I put in debug statements and every single call to FltAllocateContext
>>>> is matched by a callback to a cleanup routine, yet a few of my context
>>>> records show up as still allocated in !poolused. I assume that the
>>>> filter manager has just not gotten around to freeing them. These are
>>>> the only tagged allocations remaining and I use only tagged
>>>> allocations, so I am confident I’m not causing any pool leaks.
>>>>
>>>> So what other than pool allocations can cause the unregister to hang?
>>>> Is there a list somewhere of things that can cause this?
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>