Hi
I have a X64 minifilter which hangs on Vista RC1 at unload time.
If the minifilter is loaded manually no problem occurs, the minifilter is unloaded.
If the minifilter is loaded at system start then unloading the minifilter hangs when calling the function FltUnregisterFilter.
On Win2003 X64 everything works fine.
I also used the Vista RC1 check build for testing and no assertion occurs. Is this a known issue or is there any difference between the two start moments ?
regards
horatiu
It sounds like there is an issue with your driver. This normally happens when you have contexts that have not yet been released by your driver (for example.)
Does this happen on Vista x86? If so, this is likely an issue in your driver that only manifests on Vista.
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
xxxxx@osr.com wrote:
It sounds like there is an issue with your driver. This normally happens when you have contexts that have not yet been released by your driver (for example.)
Why would not releasing context be a problem at unload? Any contexts I have that are active, when I force an unload, fltmgr destroys them automatically.
Is there some ‘special’ rule here?
m.
‘Special’? No, but your driver won’t be unloaded until all your contexts
have been released
Pete
Kernel Drivers
Windows Filesystem and Device Driver Consulting
www.KernelDrivers.com
(303)546-0300
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-264659-
xxxxx@lists.osr.com] On Behalf Of MM
Sent: Tuesday, October 03, 2006 6:29 AM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] Minifilter Unload Problem on Vista X64xxxxx@osr.com wrote:
>It sounds like there is an issue with your driver. This normally happens
when you have contexts that have not yet been released by your driver (for
example.)
>
>
Why would not releasing context be a problem at unload? Any contexts I
have that are active, when I force an unload, fltmgr destroys them
automatically.Is there some ‘special’ rule here?
m.
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17You are currently subscribed to ntfsd as: xxxxx@kerneldrivers.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Peter Scott wrote:
‘Special’? No, but your driver won’t be unloaded until all your contexts
have been released
True, but as I said, “Any contexts I have that are active, when I force
an unload, fltmgr destroys them
automatically.”.
If I have context that are ‘alive’, and I force an unload, the context
cleanup gets called for all ‘living’ context.
After that, the filter unloads. My point is ‘so what’ if there are
context still in use by the filter, fltmgr tears them all
down on unload.
This is the behavior I’ve seen, and read about… Is there some special
rule where this expected behavior doesn’t
exist?
m.
Pete
Kernel Drivers
Windows Filesystem and Device Driver Consulting
www.KernelDrivers.com
(303)546-0300>-----Original Message-----
>From: xxxxx@lists.osr.com [mailto:bounce-264659-
>xxxxx@lists.osr.com] On Behalf Of MM
>Sent: Tuesday, October 03, 2006 6:29 AM
>To: Windows File Systems Devs Interest List
>Subject: Re: [ntfsd] Minifilter Unload Problem on Vista X64
>
>xxxxx@osr.com wrote:
>
>
>
>>It sounds like there is an issue with your driver. This normally happens
>>
>>
>when you have contexts that have not yet been released by your driver (for
>example.)
>
>
>>
>>
>Why would not releasing context be a problem at unload? Any contexts I
>have that are active, when I force an unload, fltmgr destroys them
>automatically.
>
>Is there some ‘special’ rule here?
>
>m.
>
>
>—
>Questions? First check the IFS FAQ at
>https://www.osronline.com/article.cfm?id=17
>
>You are currently subscribed to ntfsd as: xxxxx@kerneldrivers.com
>To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
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
> True, but as I said, "Any contexts I have that are active, when I force
an unload, fltmgr destroys them automatically.".
No, any context with a RefCount of 1 (only owned by FltMgr) will be destroyed;
those not yet released by your driver will not. Consider also files which do not
support CTX - did you handle these with FltMgr allocated contexts?
–
King regards, Dejan
http://www.alfasp.com
File system audit, security and encryption kits.
Since all of you guys are far more experienced than I am, I must be
misunderstanding what you’ll are saying.
I just conducted an experiment; I modified the CTX sample and when it
allocates a context successfully, I
then call FltReferenceContext on it - thus incrementing its ref count.
I no where decremented it by calling FltReleaseContext. Still yet, upon
executing “fltmc unload ctx”, the debug
prints I placed in the contextCleanup routine all fire, and the driver
unloads without error.
Context were ‘alive’ and had an artificially inflated ref count; fltmgr
still seemed to handle this condition.
confused and curious,
m.
Dejan Maksimovic wrote:
>True, but as I said, “Any contexts I have that are active, when I force
>an unload, fltmgr destroys them automatically.”.
>
>No, any context with a RefCount of 1 (only owned by FltMgr) will be destroyed;
those not yet released by your driver will not. Consider also files which do not
support CTX - did you handle these with FltMgr allocated contexts?–
King regards, Dejan
http://www.alfasp.com
File system audit, security and encryption kits.
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
This has been my experience.
“MM” wrote in message news:xxxxx@ntfsd…
> Since all of you guys are far more experienced than I am, I must be
> misunderstanding what you’ll are saying.
>
> I just conducted an experiment; I modified the CTX sample and when it
> allocates a context successfully, I
> then call FltReferenceContext on it - thus incrementing its ref count.
>
> I no where decremented it by calling FltReleaseContext. Still yet, upon
> executing “fltmc unload ctx”, the debug
> prints I placed in the contextCleanup routine all fire, and the driver
> unloads without error.
>
> Context were ‘alive’ and had an artificially inflated ref count; fltmgr
> still seemed to handle this condition.
>
> confused and curious,
>
> m.
>
>
>
> Dejan Maksimovic wrote:
>
>>>True, but as I said, “Any contexts I have that are active, when I force
>>>an unload, fltmgr destroys them automatically.”.
>>>
>>
>> No, any context with a RefCount of 1 (only owned by FltMgr) will
>> be destroyed;
>>those not yet released by your driver will not. Consider also files which
>>do not
>>support CTX - did you handle these with FltMgr allocated contexts?
>>
>>–
>>King regards, Dejan
>>http://www.alfasp.com
>>File system audit, security and encryption kits.
>>
>>
>>
>>—
>>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
>>
>>
>
Hmm, I am even more confused, as I found the exact opposite… I will recheck that.
For your problem, use PoolMon and check which of your tags and FltMgr tags are used
during the unload.
MM wrote:
Since all of you guys are far more experienced than I am, I must be
misunderstanding what you’ll are saying.I just conducted an experiment; I modified the CTX sample and when it
allocates a context successfully, I
then call FltReferenceContext on it - thus incrementing its ref count.I no where decremented it by calling FltReleaseContext. Still yet, upon
executing “fltmc unload ctx”, the debug
prints I placed in the contextCleanup routine all fire, and the driver
unloads without error.Context were ‘alive’ and had an artificially inflated ref count; fltmgr
still seemed to handle this condition.confused and curious,
–
King regards, Dejan
http://www.alfasp.com
File system audit, security and encryption kits.
Err no this is not my experience - my bad. My expierence is that if I hold
no extraneous refs to contexts - ie only the ones held by fltmgr are
present - all is torn down. I code on assumption that I have to release mine
own extra refs.
“MM” wrote in message news:xxxxx@ntfsd…
> Since all of you guys are far more experienced than I am, I must be
> misunderstanding what you’ll are saying.
>
> I just conducted an experiment; I modified the CTX sample and when it
> allocates a context successfully, I
> then call FltReferenceContext on it - thus incrementing its ref count.
>
> I no where decremented it by calling FltReleaseContext. Still yet, upon
> executing “fltmc unload ctx”, the debug
> prints I placed in the contextCleanup routine all fire, and the driver
> unloads without error.
>
> Context were ‘alive’ and had an artificially inflated ref count; fltmgr
> still seemed to handle this condition.
>
> confused and curious,
>
> m.
>
>
>
> Dejan Maksimovic wrote:
>
>>>True, but as I said, “Any contexts I have that are active, when I force
>>>an unload, fltmgr destroys them automatically.”.
>>>
>>
>> No, any context with a RefCount of 1 (only owned by FltMgr) will
>> be destroyed;
>>those not yet released by your driver will not. Consider also files which
>>do not
>>support CTX - did you handle these with FltMgr allocated contexts?
>>
>>–
>>King regards, Dejan
>>http://www.alfasp.com
>>File system audit, security and encryption kits.
>>
>>
>>
>>—
>>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
>>
>>
>
Same here. Thought I was loosing my wits, due to extraneous weather changes 
“Lyndon J. Clarke” wrote:
Err no this is not my experience - my bad. My expierence is that if I hold
no extraneous refs to contexts - ie only the ones held by fltmgr are
present - all is torn down. I code on assumption that I have to release mine
own extra refs.“MM” wrote in message news:xxxxx@ntfsd…
> > Since all of you guys are far more experienced than I am, I must be
> > misunderstanding what you’ll are saying.
> >
> > I just conducted an experiment; I modified the CTX sample and when it
> > allocates a context successfully, I
> > then call FltReferenceContext on it - thus incrementing its ref count.
> >
> > I no where decremented it by calling FltReleaseContext. Still yet, upon
> > executing “fltmc unload ctx”, the debug
> > prints I placed in the contextCleanup routine all fire, and the driver
> > unloads without error.
> >
> > Context were ‘alive’ and had an artificially inflated ref count; fltmgr
> > still seemed to handle this condition.
> >
> > confused and curious,
> >
> > m.
> >
> >
> >
> > Dejan Maksimovic wrote:
> >
> >>>True, but as I said, “Any contexts I have that are active, when I force
> >>>an unload, fltmgr destroys them automatically.”.
> >>>
> >>
> >> No, any context with a RefCount of 1 (only owned by FltMgr) will
> >> be destroyed;
> >>those not yet released by your driver will not. Consider also files which
> >>do not
> >>support CTX - did you handle these with FltMgr allocated contexts?
> >>
> >>–
> >>King regards, Dejan
> >>http://www.alfasp.com
> >>File system audit, security and encryption kits.
> >>
> >>
> >>
> >>—
> >>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
> >>
> >>
> >
>
> —
> Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@alfasp.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
–
King regards, Dejan
http://www.alfasp.com
File system audit, security and encryption kits.
Grr, I really thought the fltmgr cleaned up after sloppy code on unload.
After getting home tonight and reading both of your responses,
I spent a while writing a driver from scratch to test further, my test
with CTX last night had to be flawed some how, but how? I didn’t
see anything that jumped out at me, and my DbgPrints were all showing in
the right places… It built fine without error, prefast, /w4,
no exceptions when run and unloaded smoothly…
After writing a new driver tonight (that worked as you’ll described),
and comparing it too my modified CTX sample (from last night), I finally
saw my mistake…
I called FltReferenceContext(&MyContext). “&” <- I don’t like these
“Damn it” errors. I can’t think of the last time I made this type of
mistake and didn’t have build throw the ‘indirection’ error.
“I code on assumption that I have to release mine own extra refs.” - I
agree Lyndon, I’ve always cleaned up the ref count in my own code,
except for
the two test I’ve ran in the last two nights.
m.
Hey, it happens I’ve so often posted a question here after a week or more of
trying, and found an answer 2 minutes after I hit Send, or less. Sometimes it helps
to write out loud.
MM wrote:
Grr, I really thought the fltmgr cleaned up after sloppy code on unload.
After getting home tonight and reading both of your responses,
I spent a while writing a driver from scratch to test further, my test
with CTX last night had to be flawed some how, but how? I didn’t
see anything that jumped out at me, and my DbgPrints were all showing in
the right places… It built fine without error, prefast, /w4,
no exceptions when run and unloaded smoothly…After writing a new driver tonight (that worked as you’ll described),
and comparing it too my modified CTX sample (from last night), I finally
saw my mistake…
I called FltReferenceContext(&MyContext). “&” <- I don’t like these
“Damn it” errors. I can’t think of the last time I made this type of
mistake and didn’t have build throw the ‘indirection’ error.“I code on assumption that I have to release mine own extra refs.” - I
agree Lyndon, I’ve always cleaned up the ref count in my own code,
except for
the two test I’ve ran in the last two nights.m.
Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@alfasp.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
–
King regards, Dejan
http://www.alfasp.com
File system audit, security and encryption kits.
It is can cause quite a lot of fun and games when one makes this slip with
ObDereferenceObject …
“MM” wrote in message news:xxxxx@ntfsd…
> Grr, I really thought the fltmgr cleaned up after sloppy code on unload.
> After getting home tonight and reading both of your responses,
> I spent a while writing a driver from scratch to test further, my test
> with CTX last night had to be flawed some how, but how? I didn’t
> see anything that jumped out at me, and my DbgPrints were all showing in
> the right places… It built fine without error, prefast, /w4,
> no exceptions when run and unloaded smoothly…
>
> After writing a new driver tonight (that worked as you’ll described), and
> comparing it too my modified CTX sample (from last night), I finally saw
> my mistake…
> I called FltReferenceContext(&MyContext). “&” <- I don’t like these “Damn
> it” errors. I can’t think of the last time I made this type of
> mistake and didn’t have build throw the ‘indirection’ error.
>
> “I code on assumption that I have to release mine own extra refs.” - I
> agree Lyndon, I’ve always cleaned up the ref count in my own code, except
> for
> the two test I’ve ran in the last two nights.
>
> m.
>
Hi
I’ve investigated the problem and here my code because of which the minifilter can’t be loaded:
I have the following functions for IRP_MJ_DIRECTORY_CONTROL:
{ IRP_MJ_DIRECTORY_CONTROL,
0,
PreOperationPassThrough,
PostOperationPassThrough
},
ULONG_PTR OperationStatusCtx = 1;
and the functions:
/*************************************************************************
MiniFilter callback routines.
*************************************************************************/
FLT_PREOP_CALLBACK_STATUS
PreOperationPassThrough (
IN OUT PFLT_CALLBACK_DATA Data,
IN PCFLT_RELATED_OBJECTS FltObjects,
OUT PVOID *CompletionContext
)
/*++
Routine Description:
This routine is the main pre-operation dispatch routine for this
miniFilter. Since this is just a simple passThrough miniFilter it
does not do anything with the callbackData but rather return
FLT_PREOP_SUCCESS_WITH_CALLBACK thereby passing it down to the next
miniFilter in the chain.
This is non-pageable because it could be called on the paging path
Arguments:
Data - Pointer to the filter callbackData that is passed to us.
FltObjects - Pointer to the FLT_RELATED_OBJECTS data structure containing
opaque handles to this filter, instance, its associated volume and
file object.
CompletionContext - The context for the completion routine for this
operation.
Return Value:
The return value is the status of the operation.
–*/
{
NTSTATUS status;
UNREFERENCED_PARAMETER( FltObjects );
UNREFERENCED_PARAMETER( CompletionContext );
DbgPrint(“PassThrough!PtPreOperationPassThrough: Entered\n”);
//
// See if this is an operation we would like the operation status
// for. If so request it.
//
// NOTE: most filters do NOT need to do this. You only need to make
// this call if, for example, you need to know if the oplock was
// actually granted.
//
if (DoRequestOperationStatus( Data )) {
DbgBreakPoint();
status = FltRequestOperationStatusCallback( Data,
OperationStatusCallback,
(PVOID)(++OperationStatusCtx) );
if (!NT_SUCCESS(status)) {
DbgPrint((“PassThrough!PtPreOperationPassThrough: FltRequestOperationStatusCallback Failed, status=%08x\n”,
status) );
}
}
return FLT_PREOP_SUCCESS_WITH_CALLBACK;
}
BOOLEAN
DoRequestOperationStatus(
IN PFLT_CALLBACK_DATA Data
)
/*++
Routine Description:
This identifies those operations we want the operation status for. These
are typically operations that return STATUS_PENDING as a normal completion
status.
Arguments:
Return Value:
TRUE - If we want the operation status
FALSE - If we don’t
–*/
{
PFLT_IO_PARAMETER_BLOCK iopb = Data->Iopb;
//
// return boolean state based on which operations we are interested in
//
return (BOOLEAN)
//
// Check for oplock operations
//
FLT_IS_IRP_OPERATION(Data) &&
(((iopb->MajorFunction == IRP_MJ_FILE_SYSTEM_CONTROL) &&
((iopb->Parameters.FileSystemControl.Common.FsControlCode == FSCTL_REQUEST_FILTER_OPLOCK) ||
(iopb->Parameters.FileSystemControl.Common.FsControlCode == FSCTL_REQUEST_BATCH_OPLOCK) ||
(iopb->Parameters.FileSystemControl.Common.FsControlCode == FSCTL_REQUEST_OPLOCK_LEVEL_1) ||
(iopb->Parameters.FileSystemControl.Common.FsControlCode == FSCTL_REQUEST_OPLOCK_LEVEL_2)))
||
//
// Check for directy change notification
//
((iopb->MajorFunction == IRP_MJ_DIRECTORY_CONTROL) &&
(iopb->MinorFunction == IRP_MN_NOTIFY_CHANGE_DIRECTORY))
);
}
VOID
OperationStatusCallback (
IN PCFLT_RELATED_OBJECTS FltObjects,
IN PFLT_IO_PARAMETER_BLOCK IopbSnapshot,
IN NTSTATUS OperationStatus,
IN PVOID RequesterContext
)
/*++
Routine Description:
This routine is called when the given operation returns from the call
to IoCallDriver. This is useful for operations where STATUS_PENDING
means the operation was successfully queued. This is useful for OpLocks
and directory change notification operations.
This callback is called in the context of the originating thread and will
never be called at DPC level. The file object has been correctly
referenced so that you can access it. It will be automatically
dereferenced upon return.
This is non-pageable because it could be called on the paging path
Arguments:
FltObjects - Pointer to the FLT_RELATED_OBJECTS data structure containing
opaque handles to this filter, instance, its associated volume and
file object.
RequesterContext - The context for the completion routine for this
operation.
OperationStatus -
Return Value:
The return value is the status of the operation.
–*/
{
DbgPrint(“PassThrough!PtOperationStatusCallback: Entered\n”) );
DbgPrint(“PassThrough!PtOperationStatusCallback: Status=%08x ctx=%p IrpMj=%02x.%02x "%s"\n”,
OperationStatus,
RequesterContext,
IopbSnapshot->MajorFunction,
IopbSnapshot->MinorFunction,
FltGetIrpName(IopbSnapshot->MajorFunction)) );
}
if the IRP_MJ_DIRECTORY_CONTROL with IRP_MN_NOTIFY_CHANGE_DIRECTORY arrives I can’t unload the minifilter anymore.
There is no context referenced so there should be no problem. Also in the DDK is nothing that mentions a neccessary call to unreference a certain object.
Can maybe someone from MS take a look on it.
thanks
horatiu