Kedar,
It sounds as though the reference counting is correct but you are not
waiting long enough. Only as a test, when all of the references from the
IRP_MJ_CREATE have been de-referenced through the corresponding
IRP_MJ_CLOSE, you can try to purge the cache. This will force the MM to
release its reference on it, if it can. If the file is memory mapped then
this will fail.
At least this will tell you that when you do get the final IRP_MJ_CLOSE your
code paths will work correctly. I would not leave this test in there though.
Again, from your description, the final close is just not happening, which
is a very typical scenario.
Pete
Kernel Drivers
Windows Filesystem and Device Driver Consulting
www.KernelDrivers.com
(303)546-0300
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of kedar
Sent: Monday, May 16, 2005 4:50 AM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Denying Reads… but the data is reached to the
application
Hi Pete,
I have followed all three steps in my code that you have mentioned. But
still I do not see the final close.
I have also observed whether that close is coming while the system is
getting restarted but I could not find that last close.
And I always see ImageSectionobject pointer as NULL and DataSectionObject
never becomes NULL in IRP_MJ_CLOSE.
I have observed that number of CREATE’s is greater than number of CLOSE’s by
one.
I am testing this on Windows 2000 system on which no Service packs are
installed. Can this be any of the problem.
Thanks,
Kedar.
“Peter Scott” wrote in message
news:xxxxx@ntfsd…
>
> There could be two reasons for this.
>
> 1. Your code is implemented incorrectly and your referencing counting is
> off.
>
> 2. Your code is implemented correctly but you are not waiting long enough.
> Remember that the memory manager probably has the final reference on the
> file and it will not release this reference until it needs to use those
> resources for some other purposes. So it could be a long time, and this is
> non-deterministic, before you see the final close on the file.
>
> I suspect that if you are doing everything correctly, your count would
> drop
> to zero but you would not remove the node from your hash table due to the
> SOP pointers being non-null, but this won’t always apply.
>
> Your code should reflect the following, per the article:
>
> - The reference count shows how many fileobjects were processed through
> the
> IRP_MJ_CREATE handler. Hence you increment it for each IRP_MJ_CREATE on a
> given FsContext you see on the completion side.
>
> - Decrement the count when the FO_STREAM_FILE bit is not set in the
> fileobject when you receive an IRP_MJ_CLOSE.
>
> - Remove it when the count is zero and the ImageSectionObject and
> DataSectionObject are both NULL.
>
> Pete
>
> Kernel Drivers
> Windows Filesystem and Device Driver Consulting
> www.KernelDrivers.com
> (303)546-0300
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of kedar
> Sent: Saturday, May 14, 2005 7:12 AM
> To: Windows File Systems Devs Interest List
> Subject: Re:[ntfsd] Denying Reads… but the data is reached to the
> application
>
> Hi Pete,
>
> As the OSR article says in IRP_MJ_CLOSE I never see DataSectionObject
> pointer as NULL. Am I missing something. And when I do refernce count I am
> always stopping at Count 1 and the it never reduces to 0.
>
> Could you please tell my why this is happening.
>
> Thanks,
> Kedar.
>
> “Peter Scott” wrote in message
> news:xxxxx@ntfsd…
>>
>> Kedar,
>>
>> Please read the OSR article on referencing counting for filters.
>>
>> To answer your question, do not use the fileobject as a lookup index in
>> your hash table. Use the FileObject->FsContext retrieved on the
>> completion
>> side of IRP_MJ_CREATE. Then in the IRP_MJ_READ check this value. You are
>> missing the stream FO’s created by the underlying FSD to initialize
>> caching
>> and hence paging is made under these fileobjects. These fileobjects you
>> will
>> not see through the IRP_MJ_CREATE pathway.
>>
>> I think this is a record. I have answered this same question twice in 3
>> days:! Again, please read the article at www.osronline.com.
>>
>> Pete
>>
>> Kernel Drivers
>> Windows Filesystem and Device Driver Consulting
>> www.KernelDrivers.com
>> (303)546-0300
>>
>>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com] On Behalf Of kedar
>> Sent: Thursday, May 12, 2005 10:51 AM
>> To: Windows File Systems Devs Interest List
>> Subject: Re:[ntfsd] Denying Reads… but the data is reached to the
>> application
>>
>> Hi Pete,
>>
>> In the create I am getting the name and then compare the name and of the
>> name is of interest then I add that to hash.
>>
>> In the read I check the hash if the fileobject is found in the hash then
>> I
>> mark as pending. And from other thread I complete it putting Status =
>> STATUS_PENDING.
>>
>> Thanks,
>> Kedar.
>>
>> “Peter Scott” wrote in message
>> news:xxxxx@ntfsd…
>>>
>>> Yes, they do come under the IRP_MJ_READ dispatch handler. My question is
>>> how
>>> are you determining that a particular read is for a file that you are
>>> interested in? Are you making this determination by comparing the
>>> fileobject
>>> you received in your IRP_MJ_CREATE dispatch handler to the one in the
>>> IRP_MJ_READ dispatch handler? Or are you comparing FsContext pointers or
>>> some other method?
>>>
>>> Pete
>>>
>>> Kernel Drivers
>>> Windows Filesystem and Device Driver Consulting
>>> www.KernelDrivers.com
>>> (303)546-0300
>>>
>>>
>>> -----Original Message-----
>>> From: xxxxx@lists.osr.com
>>> [mailto:xxxxx@lists.osr.com] On Behalf Of kedar
>>> Sent: Thursday, May 12, 2005 10:25 AM
>>> To: Windows File Systems Devs Interest List
>>> Subject: Re:[ntfsd] Denying Reads… but the data is reached to the
>>> application
>>>
>>> Hi Pete,
>>>
>>> Does paging reads come as IRP_MJ_READ? I am catching all the IRP_MJ_READ
>>> and
>>>
>>> not checking for any flag.
>>>
>>> Please let me know if I have missed anything.
>>>
>>> Thanks,
>>> Kedar.
>>>
>>> “Peter Scott” wrote in message
>>> news:xxxxx@ntfsd…
>>>>
>>>> Kedar,
>>>>
>>>> You are probably missing the paging read requests. How are you tracking
>>>> the
>>>> read requests for the particular file? Are you handling the stream_fo
>>>> cases?
>>>>
>>>> Pete
>>>>
>>>> Kernel Drivers
>>>> Windows Filesystem and Device Driver Consulting
>>>> www.KernelDrivers.com
>>>> (303)546-0300
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: xxxxx@lists.osr.com
>>>> [mailto:xxxxx@lists.osr.com] On Behalf Of kedar
>>>> Sent: Thursday, May 12, 2005 9:42 AM
>>>> To: Windows File Systems Devs Interest List
>>>> Subject: [ntfsd] Denying Reads… but the data is reached to the
>>>> application
>>>>
>>>> Hi,
>>>>
>>>> We have a file system filter driver in which we are marking READ IRP’s
>>>> from
>>>> media player as pending in the actual IRP context and then in from
>>>> another
>>>> thread we are sending status as STATUS_ENDOF_FILE and we are sure that
>>>> we
>>>> are not sending any IRP_MJ_READ of mediaplayer to actual file system.
>>>> But
>>
>>>> to
>>>>
>>>> our surprise the Media player is able to play the file.
>>>>
>>>> Is there any other way to read the file contents other than
>>>> IRP_MJ_READ.
>>>> I
>>>> have checked fastioread and there is no fastio happening for the song.
>>>>
>>>> Any information is helpful.
>>>>
>>>> Thanks,
>>>> Kedar
>>>>
>>>>
>>>>
>>>> —
>>>> 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@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@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@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@kerneldrivers.com
To unsubscribe send a blank email to xxxxx@lists.osr.com