how to enable rundown log tracing in vista..???

NTFSD
1

i am trying to debug a filter driver in vista. i m facing some some context related problems. some contexts got lost in the logic and can not be freed so at unloading time my driver is not responding.

i come to know that vista can dump these information at unloading time…

but when i tried !fltobj 8 1 i got a string that “Rundown log tracing not enabled on this version of FLTMGR.SYS”

i m using vista ultimate edition. it is in demo mode now.

i would be thankful if u guys put some light in this that how can i enable rundown log tracing in vista.

regards
harish

2

You can’t enable it, it’s a compile time thing and it’s disabled in all builds.

What you can do is enable driver verifier for your minifilter and filter manager will keep track of a lot of references (including contexts) and will let you know if you leaked something at unload time.

Regards,
Alex.
This posting is provided “AS IS” with no warranties, and confers no rights.

3

Thankx for the reply.

but in the help of Filter Manager Debugger Extentions it is documented.

fltobj [addr] [detail] Dump FLT_OBJECT
where [flags] specify what information to dump:
0x00000001 Basic object information
0x00000002 Rundown log information on the object

my driver got hang in unload time. It is not unloaded yet so how can we 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.

did you know some other ways so that i can find 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 only free them 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

4

A couple of comments:

  1. Sure, Rundown log information is documented and it works, provided you have a filter manager compiled with that option enabled. However, I doubt you will be able to find one for the reasons I explained in the previous post.
  2. Hang != leaking resources. It is hard to find leaks in a running program in general and that’s where filter manager driver verifier helps. It will walk an internal list of objects when a minifilter calls FltUnregisterFilter and if it finds any leaks it will print an error message. The minifilter will not have unloaded at that time because the leaked objects reference it. Use !fltkd.filter 8 1 to print a list of all objects, but beware that some entries on the list might not be leaks. Regardless, by inspecting such entries you might be able to find some that were leaks and then start the investigation there.
    3. you can maintain your own list of contexts if you want but filter manager driver verifier does it for you.
    4. you MUST not keep memory that is not needed anymore until unload time. Too many reasons why this is wrong so I won’t go into that… it should be obvious…
    5. you can determine that a particular context is associated with a certain object by using !fltkd.ctx. There is a field “AttachedObject” which points to the underlying object. Please note that if you leak contexts it is possible that the OS underlying object is gone, but the FLtMgr structure will still be around (if you have only stream contexts and streamhandle contexts then “AttachedObject” will point to a STREAM_LIST_CTRL which you can print with “!fltkd.streamlist ”; however, the FILE_OBJECT or FCB that the STREAM_LIST_CTRL was associated with could have been reused!).
    6. Please don’t post the same question multiple times.

    Regards,
    Alex.
    This posting is provided “AS IS” with no warranties, and confers no rights.