Hello.
I have a FS filter driver, which is using hash for storing information about currently opened objects. This hash is based on FileObjects. I have noticed, that there is stored a few elements which should be closed and should not present in hash. I searched it with ProcessexplorerNT’s handle searcher and found nothing. After I watch on log of FileMon and have seen that, it was 3 IRP_MJ_CREATE but only 2 IRP_MJ_CLOSE for that file. I was surprised.
The article “Tracking State and Context - Reference Counting for File System Filter Drivers” (http://www.osronline.com/article.cfm?id=102) says that can be situation , when filter retreive unexpected IRP_MJ_CLOSE, but nothing about my situation.
How should I track Create/Close requests to avoid such situations ?
Best regards,
Alexey Barabash.
I guess you are confusing IRP_MJ_CLOSE and IRP_MJ_CLEANUP. The reference
count of a file object is different from the open handle count.
Read this: http://support.microsoft.com/kb/120170/en-us
wrote news:xxxxx@ntfsd…
> Hello.
>
> I have a FS filter driver, which is using hash for storing information
> about currently opened objects. This hash is based on FileObjects. I have
> noticed, that there is stored a few elements which should be closed and
> should not present in hash. I searched it with ProcessexplorerNT’s handle
> searcher and found nothing. After I watch on log of FileMon and have seen
> that, it was 3 IRP_MJ_CREATE but only 2 IRP_MJ_CLOSE for that file. I was
> surprised.
> The article “Tracking State and Context - Reference Counting for File
> System Filter Drivers” (http://www.osronline.com/article.cfm?id=102) says
> that can be situation , when filter retreive unexpected IRP_MJ_CLOSE, but
> nothing about my situation.
> How should I track Create/Close requests to avoid such situations ?
>
> Best regards,
> Alexey Barabash.
>
Thanks for interesting link.
After several hours I have noticed, that those record has dissapeared from my hash. It shows, that IRP_MJ_CLOSE was received. But it is strange, that so later.
No, it’s not strange. Cache manager may have referenced those file objects
and keep them alive for a loooong time, even after the last handle has been
gone. That’s what caching is about.
wrote news:xxxxx@ntfsd…
> Thanks for interesting link.
>
> After several hours I have noticed, that those record has dissapeared from
> my hash. It shows, that IRP_MJ_CLOSE was received. But it is strange, that
> so later.
>
Is there any reason why you are not use contexts ? They have the behavior
you need, and you don’t have to worry about the teardown - the OS can be
persuaded top do most of the work for you.
Oh yes, and days are not unusual for file objects in cache…
xxxxx@gmail.com> wrote in message news:xxxxx@ntfsd…
Hello.
I have a FS filter driver, which is using hash for storing information
about currently opened objects. This hash is based on FileObjects. I have
noticed, that there is stored a few elements which should be closed and
should not present in hash. I searched it with ProcessexplorerNT’s handle
searcher and found nothing. After I watch on log of FileMon and have seen
that, it was 3 IRP_MJ_CREATE but only 2 IRP_MJ_CLOSE for that file. I was
surprised.
The article “Tracking State and Context - Reference Counting for File
System Filter Drivers” (http://www.osronline.com/article.cfm?id=102) says
that can be situation , when filter retreive unexpected IRP_MJ_CLOSE, but
nothing about my situation.
How should I track Create/Close requests to avoid such situations ?
Best regards,
Alexey Barabash.
Yes, there is a reason. I need to store beside full path some other info (PID of process, that opened certain file, desirred access, create options, etc ) in my hash. I realize that using of FileObject instead FsContext is cannot always ensure that different process use different FileObjects, but it is considerably often and enough for my driver.
Best regards,
Alexey Barabash.
If this is a minifilter, look at stream handle contexts…
wrote in message news:xxxxx@ntfsd…
> Yes, there is a reason. I need to store beside full path some other info
> (PID of process, that opened certain file, desirred access, create
> options, etc ) in my hash. I realize that using of FileObject instead
> FsContext is cannot always ensure that different process use different
> FileObjects, but it is considerably often and enough for my driver.
>
> Best regards,
> Alexey Barabash.
>