minifilter unloading issue......

hi all

my driver got hang in unload time. It is not unloaded yet so is there any process or method so that i can find leaks. Driver verifier is giving various pool allocation related data but things are not so much clear. i thought “run down log” will help me in this.

NTSTATUS PtUnload ( FLT_FILTER_UNLOAD_FLAGS Flags )
{
UNREFERENCED_PARAMETER( Flags );

PT_DBG_PRINT( PTDBG_TRACE_ROUTINES,
(“MyDriver!PtUnload: Entered\n”) );

FltCloseCommunicationPort( MyDriverData.ServerPort );

FltUnregisterFilter( gFilterHandle );

->>>>> return STATUS_SUCCESS; ///(stuck here)
}

I have used stream handle context.

->did anyone know some other ways so that i can find or traceout various contexts which are lost in the logic ?
->do i need to maintain a list of allocated contexts and free them at unload time? if i free them only at unload time then there are chances that user might not unload the driver at all and leaked context keep growing on… then which should be the best time when i should traverse context list and free them?
->how do we determine that a particular context is associated with a valid stream or file object ?

i will be grateful if u people shed some lite on these questions. i m very much confused now.

regards
harish bisht

It’s stuck in FltUnregisterFilter, if you turn verifier on (fltmgr + your
driver), then something like “!verifier 3 drivername.sys” should inform you
about all current allocations. You can also use “!poolused” command to look
all your leaked allocations up in the list. You don’t need to free all used
contexts, they’ll be removed automatically.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: 10. ?ervence 2009 12:05
To: Windows File Systems Devs Interest List
Subject: [ntfsd] minifilter unloading issue…

hi all

my driver got hang in unload time. It is not unloaded yet so is there any
process or method so that i can find leaks. Driver verifier is giving
various pool allocation related data but things are not so much clear. i
thought “run down log” will help me in this.

NTSTATUS PtUnload ( FLT_FILTER_UNLOAD_FLAGS Flags )
{
UNREFERENCED_PARAMETER( Flags );

PT_DBG_PRINT( PTDBG_TRACE_ROUTINES,
(“MyDriver!PtUnload: Entered\n”) );

FltCloseCommunicationPort( MyDriverData.ServerPort );

FltUnregisterFilter( gFilterHandle );

->>>>> return STATUS_SUCCESS; ///(stuck here)
}

I have used stream handle context.

->did anyone know some other ways so that i can find or traceout various
contexts which are lost in the logic ?
->do i need to maintain a list of allocated contexts and free them at unload
time? if i free them only at unload time then there are chances that user
might not unload the driver at all and leaked context keep growing on…
then which should be the best time when i should traverse context list and
free them?
->how do we determine that a particular context is associated with a valid
stream or file object ?

i will be grateful if u people shed some lite on these questions. i m very
much confused now.

regards
harish bisht


NTFSD is sponsored by OSR

For our schedule of debugging and file system seminars
(including our new fs mini-filter seminar) 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