I have a minifilter hung in unload (no, it is not leaking contexts - see
below)
A priori this is because one of the instances is sticky:
FLT_OBJECT: 87e611f8 [01000003] Instance DRAINING ZOMBIED
RundownRef : 0x00000001 (0) drained
PointerCount : 0x00000003
PrimaryLink : [87c95464-810c9a5c]
OperationRundownRef : 00000000
Flags : [00000002] Deleting
Volume : 87caf008 “\Device\HarddiskVolume1”
Filter : 00000000
TrackCompletionNodes : 00000000
ContextLock : (87e61234)
Context : 00000000
CallbackNodes : (87e61244)
VolumeLink : [87c95464-810c9a5c]
FilterLink : [00000000-87e602a0]
The only thread in my filter is the one calling FltUnregisterfilter and
there are no contexts outstanding. Not only would verifier have told me,
but I can see it :
FLT_FILTER: 87e60238 “Driver” “64000”
InstanceList : (87e60268)
Resource (87e602a0) List [87e602a0-87e602a0] rCount=0
Object usage/reference information:
References to FLT_CONTEXT : 0
Allocations of FLT_CALLBACK_DATA : 0
Allocations of FLT_DEFERRED_IO_WORKITEM : 0
Allocations of FLT_GENERIC_WORKITEM : 0
References to FLT_FILE_NAME_INFORMATION : 0
Open files : 0
References to FLT_OBJECT : 0
Further verifier also says that I have nothing allocated, so things look
pretty clean.
My suspicion is that the non zero pointer count in the Instance Object is
involved. But I have no idea what that might mean and googling the usual
suspects hasn’t shown anything (except an interesting article in Wikipedia
about a pandemic in WoW - who knew computer games had such interesting
bugs!)
Thanks
/Rod
Hi Rod,
You are right, zombied means that there are still references to it. FltMgr
uses rundown references and pointer references. When the rundown reference
count reaches 0 the object is cleaned up (unlinked from lists, members are
freed and so on) and then when the pointer count reaches 0 the memory is
freed.
You would see this behavior (nothing left over but pointer count != 0 ) if
you were leaking references. I’m not saying that’s the case, but if it were
it would look something like this.
Thanks,
Alex.
Thanks Alex
You would see this behavior (nothing left over but pointer count != 0 ) if
you were leaking references. I’m not saying that’s the case, but if it
were
it would look something like this.
That’s what I thought might be up, but what would I have reference on? Any
contexts, CBD, FileObjects or FileNameInformation would show up as leaked
contexts and I don’t have any of those. And it tells me that I don’t have
any references on FLT_OBJECTS either.
So I have to assume that something else has grabbed a reference on my
behalf, but what on? and how? and what did I do to provoke it…
I’ll keep on poking and see what I can find…
Rod
Well, the reference would be on the instance… Also I think that the “Object usage/reference information” is only valid if you have verifier enabled.
Do you call FltObjectReference() in your filter at all ?
Thanks,
Alex.
> Well, the reference would be on the instance… Also I think that the
“Object usage/reference information” is only valid if you have verifier
enabled.
Verifier is on (which is how I know that I have no pool outstanding).
Do you call FltObjectReference() in your filter at all ?
I don’t think I have have had the need and certainly this filter doesn’t do
this. There is but one call to FltObjectDereference (to match a call to
FltGetVolumeFromName), which makes me realize I need to check for other
inferred references with lost dereferences in error paths…
I should add that this is not a mainline error - it it reproducible to a
degree, but only under fairly limited circumstances…
Rod