Reference counting, yet again

OSR_Community_User · April 3, 2004, 5:22am

In the NT Insider article on reference counting, it is said to
discard the hash entry when Data and Image section objects are both
non-NULL, which was false.
But, I am having trouble with the opposite as well…
A very simple case: notepad opening editing and saving boot.ini
Section object pointer is non NULL, the image is NULL and Data is
non-null. Obviously I don’t free the hash entry.
Problem? I see an open later with the FsContext that corresponds to
the FsContext in this hash entry.

Ideas?

–
Kind regards, Dejan M. MVP for DDK
http://www.alfasp.com E-mail: xxxxx@alfasp.com
Alfa Transparent File Encryptor - Transparent file encryption services.
Alfa File Protector - File protection and hiding library for Win32
developers.
Alfa File Monitor - File monitoring library for Win32 developers.

OSR_Community_User · April 3, 2004, 8:29am

Dejan,

Let me see if I get this correctly:

In the completion routine of your IRP_MJ_CREATE handler, you see a
FileObject->FsContext value that matches something in your tracking
structure, but it has a different value for
FileObject->SectionObjectPointers?

If this is the case, perhaps you can give us some more details: the
version of Windows, the file system involved and confirmation that you
do not have any other filters on the stack (or if you do, which
filters.)

I suppose this is possible (I’ve previously suggested using
SectionObjectPointers as the lookup key, but never pushed the issue on
the presumption that the FsContext and SectionObjectPointer values
should change together.) In the FAT sample of the IFS Kit, it allocates
the FCB separately from the SOP structure
(FCB->NonPagedFcb.SectionObjectPointers is what is used for the SOP
address.) Thus, I suppose it might be tolerable for the FsContext to be
recycled when the SOP is not, although I don’t see any code paths in FAT
that would do that.

So, my question would be: if MM still held a reference on a file object
(SOP was non-NULL) then how did it get rid of it without decrementing
the reference count on the file? The ONLY way I could see this happen
is if someone bumped the ref count on the file object outside MM and
then MM decremented the ref count on the section - but then the ref
count on the file object would still be elevated and the FSD wouldn’t
recycle it yet. And even if we hypothesize some odd case (like around
some internal controlled file for the FSD that it decremented the ref
count on) it doesn’t fit with notepad opening a file like boot.ini…

More details please!

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Dejan Maksimovic
Sent: Saturday, April 03, 2004 5:22 AM
To: ntfsd redirect
Subject: [ntfsd] Reference counting, yet again

In the NT Insider article on reference counting, it is said to
discard the hash entry when Data and Image section objects are both
non-NULL, which was false.
But, I am having trouble with the opposite as well…
A very simple case: notepad opening editing and saving boot.ini
Section object pointer is non NULL, the image is NULL and Data is
non-null. Obviously I don’t free the hash entry.
Problem? I see an open later with the FsContext that corresponds to
the FsContext in this hash entry.

Ideas?

–
Kind regards, Dejan M. MVP for DDK
http://www.alfasp.com E-mail: xxxxx@alfasp.com Alfa Transparent File
Encryptor - Transparent file encryption services.
Alfa File Protector - File protection and hiding library for Win32
developers.
Alfa File Monitor - File monitoring library for Win32 developers.

Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@osr.com To unsubscribe
send a blank email to xxxxx@lists.osr.com

OSR_Community_User · April 3, 2004, 10:35am

Tony,

In the completion routine of your IRP_MJ_CREATE handler, you see a
FileObject->FsContext value that matches something in your tracking structure, but
it has a different value for
FileObject->SectionObjectPointers?

(Not in completion, in dispatch after waiting on event set by completion
after IoCallDriver)
I do not check SOP at this time - just FsContext. When I try to log the file
object, I see I already have a hash with the FsContext which is the same as for this
new FO.
Problem is really I didn’t get an IRP_MJ_CLOSE for a certain file object
during a Windows session (between Boot and Shutdown).
Debugging through hash cleanup, I see the SoB is non-NULL, Image is NULL,
data is non-NULL and that I also have one FO logged into this hash - so it’s not the
algorithm of checking Data and Image pointers that is problematic.

If this is the case, perhaps you can give us some more details: the
version of Windows, the file system involved and confirmation that you do not have
any other filters on the stack (or if you do, which
filters.)

XP SP1a, Dual P3, there are 5 filters on the stack, but same happens with
this filter alone. NTFS of course.

–
Kind regards, Dejan M. MVP for DDK
http://www.alfasp.com E-mail: xxxxx@alfasp.com
Alfa Transparent File Encryptor - Transparent file encryption services.
Alfa File Protector - File protection and hiding library for Win32 developers.
Alfa File Monitor - File monitoring library for Win32 developers.

OSR_Community_User · April 3, 2004, 2:43pm

Dejan,

OK. Again, I am trying to understand why you think this is a different
file. I’m sure there’s something you are seeing that is convincing you,
but I’m unclear on that missing detail.

If the file object has the same FCB but is a different file, then the
only thing I can assume is that there is some IRP_MJ_CLOSE path
bypassing your filter. To verify that this is the case, you can always
grab the NTFS IRP_MJ_CLOSE handler (and, of course, this is diagnostic
and not something for shipping product) and ensure that you aren’t
missing an IRP_MJ_CLOSE. The other thing to check is the SOP structure.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Dejan Maksimovic
Sent: Saturday, April 03, 2004 10:35 AM
To: ntfsd redirect
Subject: Re: [ntfsd] Reference counting, yet again

Tony,

In the completion routine of your IRP_MJ_CREATE handler, you see a
FileObject->FsContext value that matches something in your tracking
FileObject->structure, but
it has a different value for
FileObject->SectionObjectPointers?

(Not in completion, in dispatch after waiting on event set by
completion after IoCallDriver)
I do not check SOP at this time - just FsContext. When I try to
log the file object, I see I already have a hash with the FsContext
which is the same as for this new FO.
Problem is really I didn’t get an IRP_MJ_CLOSE for a certain
file object during a Windows session (between Boot and Shutdown).
Debugging through hash cleanup, I see the SoB is non-NULL, Image
is NULL, data is non-NULL and that I also have one FO logged into this
hash - so it’s not the algorithm of checking Data and Image pointers
that is problematic.

If this is the case, perhaps you can give us some more details: the
version of Windows, the file system involved and confirmation that you

do not have any other filters on the stack (or if you do, which
filters.)

XP SP1a, Dual P3, there are 5 filters on the stack, but same
happens with this filter alone. NTFS of course.

–
Kind regards, Dejan M. MVP for DDK
http://www.alfasp.com E-mail: xxxxx@alfasp.com Alfa Transparent File
Encryptor - Transparent file encryption services.
Alfa File Protector - File protection and hiding library for Win32
developers.
Alfa File Monitor - File monitoring library for Win32 developers.

Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@osr.com To unsubscribe
send a blank email to xxxxx@lists.osr.com

OSR_Community_User · April 3, 2004, 5:50pm

Tony,

I’m definitely not getting a close, at least not before I have to get it. In
a simply scenario where I just edit a file and reboot, my filter is supposed to write
a “end of session” entry into a log file. This entry is never written to the file,
since I don’t get a last close to match in my structures.
The particular case where I saw an open with same FCB but different file name
(it was not a renamed file, BTW, which would explain it) I cannot reproduce. So now,
it’s… why am I not getting a close during a windows session… or am I getting it
too late, to be able to write to a file at that point.
My primary concern is for what pointers to check… if I missed a close
somehow, that would explain left over FO links in my hashes, but not why Image
section object is non-null.

Regards, Dejan.

Tony Mason wrote:

Dejan,

OK. Again, I am trying to understand why you think this is a different file. I’m
sure there’s something you are seeing that is convincing you, but I’m unclear on
that missing detail.

If the file object has the same FCB but is a different file, then the
only thing I can assume is that there is some IRP_MJ_CLOSE path
bypassing your filter. To verify that this is the case, you can always
grab the NTFS IRP_MJ_CLOSE handler (and, of course, this is diagnostic and not
something for shipping product) and ensure that you aren’t missing an
IRP_MJ_CLOSE. The other thing to check is the SOP structure.

–
Kind regards, Dejan M. MVP for DDK
http://www.alfasp.com E-mail: xxxxx@alfasp.com
Alfa Transparent File Encryptor - Transparent file encryption services.
Alfa File Protector - File protection and hiding library for Win32 developers.
Alfa File Monitor - File monitoring library for Win32 developers.

OSR_Community_User · April 3, 2004, 6:11pm

Dejan,

It is indeed very troubling. Either the close is bypassing your filter,
or the FCB and the NONPAGED_FCB are not tracking one-to-one, neither of
which would be very good news.

I’m assuming the new name on this object isn’t something bizzare (open
by ID, for example…) I’m trying to think of some simple way to figure
this out, but I fear it is going to require a repro case and a lot of
concerted tracing to find out the root cause.

If I can be of any assistance, let me know.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Dejan Maksimovic
Sent: Saturday, April 03, 2004 5:50 PM
To: ntfsd redirect
Subject: Re: [ntfsd] Reference counting, yet again

Tony,

I’m definitely not getting a close, at least not before I have
to get it. In a simply scenario where I just edit a file and reboot, my
filter is supposed to write a “end of session” entry into a log file.
This entry is never written to the file, since I don’t get a last close
to match in my structures.
The particular case where I saw an open with same FCB but
different file name (it was not a renamed file, BTW, which would explain
it) I cannot reproduce. So now, it’s… why am I not getting a close
during a windows session… or am I getting it too late, to be able to
write to a file at that point.
My primary concern is for what pointers to check… if I missed
a close somehow, that would explain left over FO links in my hashes, but
not why Image section object is non-null.

Regards, Dejan.

Tony Mason wrote:

Dejan,

OK. Again, I am trying to understand why you think this is a
different file. I’m sure there’s something you are seeing that is
convincing you, but I’m unclear on that missing detail.

If the file object has the same FCB but is a different file, then the
only thing I can assume is that there is some IRP_MJ_CLOSE path
bypassing your filter. To verify that this is the case, you can
always grab the NTFS IRP_MJ_CLOSE handler (and, of course, this is
diagnostic and not something for shipping product) and ensure that you

aren’t missing an IRP_MJ_CLOSE. The other thing to check is the SOP
structure.

–
Kind regards, Dejan M. MVP for DDK
http://www.alfasp.com E-mail: xxxxx@alfasp.com Alfa Transparent File
Encryptor - Transparent file encryption services.
Alfa File Protector - File protection and hiding library for Win32
developers.
Alfa File Monitor - File monitoring library for Win32 developers.

Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@osr.com To unsubscribe
send a blank email to xxxxx@lists.osr.com

OSR_Community_User · April 3, 2004, 6:50pm

Tony,

There is definitely no open by ID on the system between boot and shutdown (I
do DbgBreakPoint to trace Open by ID, but I never got a breakpoint).

It would be easy if this was a crash, as I could just send a crash dump.

I’ll do a test on an FAT volume tomorrow.

Regards, Dejan.

Tony Mason wrote:

Dejan,

It is indeed very troubling. Either the close is bypassing your filter,
or the FCB and the NONPAGED_FCB are not tracking one-to-one, neither of which would
be very good news.

I’m assuming the new name on this object isn’t something bizzare (open by ID, for
example…) I’m trying to think of some simple way to figure this out, but I fear
it is going to require a repro case and a lot of concerted tracing to find out the
root cause.

If I can be of any assistance, let me know.

–
Kind regards, Dejan M. MVP for DDK
http://www.alfasp.com E-mail: xxxxx@alfasp.com
Alfa Transparent File Encryptor - Transparent file encryption services.
Alfa File Protector - File protection and hiding library for Win32 developers.
Alfa File Monitor - File monitoring library for Win32 developers.

OSR_Community_User · April 4, 2004, 12:04pm

You indicate that you may be ‘getting the close too late to be able to write
to the file.’ I presume this is during shutdown processing and your check is
after reboot you see the data was not flushed correctly to the file in
question.

This does happen if you simply register for shutdown notification through
the IoRegxxx api. Since shutdown irps are not called in a ‘layered’ model,
there is no deterministic way to say your shutdown routine will be called
before or after the shutdown for NTFS shutdown routine. Therefore your
shutdown routine could be called after the NTFS driver and therefore when
you try and write out data it is failing.

One way to check this is to hook the NTFS shutdown routine and see if it is
getting called before or after your driver’s shutdown routine. Again, this
would be only for diagnostics and not for actual production, as Tony noted.

Pete

Peter Scott
xxxxx@KernelDrivers.com
www.KernelDrivers.com

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-171750-
xxxxx@lists.osr.com] On Behalf Of Dejan Maksimovic
Sent: Saturday, April 03, 2004 5:50 PM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] Reference counting, yet again

Tony,

I’m definitely not getting a close, at least not before I have to
get it. In
a simply scenario where I just edit a file and reboot, my filter is
supposed to write
a “end of session” entry into a log file. This entry is never written to
the file,
since I don’t get a last close to match in my structures.
The particular case where I saw an open with same FCB but
different file name
(it was not a renamed file, BTW, which would explain it) I cannot
reproduce. So now,
it’s… why am I not getting a close during a windows session… or am I
getting it
too late, to be able to write to a file at that point.
My primary concern is for what pointers to check… if I missed a
close
somehow, that would explain left over FO links in my hashes, but not why
Image
section object is non-null.

Regards, Dejan.

Tony Mason wrote:

> Dejan,
>
> OK. Again, I am trying to understand why you think this is a different
file. I’m
> sure there’s something you are seeing that is convincing you, but I’m
unclear on
> that missing detail.
>
> If the file object has the same FCB but is a different file, then the
> only thing I can assume is that there is some IRP_MJ_CLOSE path
> bypassing your filter. To verify that this is the case, you can always
> grab the NTFS IRP_MJ_CLOSE handler (and, of course, this is diagnostic
and not
> something for shipping product) and ensure that you aren’t missing an
> IRP_MJ_CLOSE. The other thing to check is the SOP structure.

–
Kind regards, Dejan M. MVP for DDK
http://www.alfasp.com E-mail: xxxxx@alfasp.com
Alfa Transparent File Encryptor - Transparent file encryption services.
Alfa File Protector - File protection and hiding library for Win32
developers.
Alfa File Monitor - File monitoring library for Win32 developers.

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

OSR_Community_User · April 4, 2004, 12:15pm

I do nothing in IRP_MJ_SHUTDOWN.
What I do is free hash during IRP_MJ_CLOSE. If that was the last file close (no
more FOs in the list, Image and Data pointers are NULL), then I add a list entry to
write to a log file.
A system thread would then check the list, and write out information to all log
files it’s supposed to write to. I don’t wait on the thread to finish processing
though.
If I let the OS run long enough (10 minutes I guess), the last close occurs, the
log file is written to.
A purge during close MIGHT help, which I’ll try, but I believe this can cause
deadlocks?

Regards, Dejan.

Peter Scott wrote:

You indicate that you may be ‘getting the close too late to be able to write
to the file.’ I presume this is during shutdown processing and your check is
after reboot you see the data was not flushed correctly to the file in
question.

This does happen if you simply register for shutdown notification through
the IoRegxxx api. Since shutdown irps are not called in a ‘layered’ model,
there is no deterministic way to say your shutdown routine will be called
before or after the shutdown for NTFS shutdown routine. Therefore your
shutdown routine could be called after the NTFS driver and therefore when
you try and write out data it is failing.

One way to check this is to hook the NTFS shutdown routine and see if it is
getting called before or after your driver’s shutdown routine. Again, this
would be only for diagnostics and not for actual production, as Tony noted.

–
Kind regards, Dejan M. MVP for DDK
http://www.alfasp.com E-mail: xxxxx@alfasp.com
Alfa Transparent File Encryptor - Transparent file encryption services.
Alfa File Protector - File protection and hiding library for Win32 developers.
Alfa File Monitor - File monitoring library for Win32 developers.

OSR_Community_User · April 4, 2004, 1:18pm

Have you ensured that all of your log files are flushed prior to shutdown?

I have definitely encountered situations where there are no close requests
processed for files before shutdown though all dirty data for that
particular file is flushed by the underlying FSD during shutdown processing.

Try registering for shutdown notification and flushing your log files at
that time. Again, if the FSD you are calling has already received the
shutdown request, then you will receive an error code back during your
writes. See the Fat write processing for more information on this.

Pete

Peter Scott
xxxxx@KernelDrivers.com
www.KernelDrivers.com

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-171789-
xxxxx@lists.osr.com] On Behalf Of Dejan Maksimovic
Sent: Sunday, April 04, 2004 12:15 PM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] Reference counting, yet again

I do nothing in IRP_MJ_SHUTDOWN.
What I do is free hash during IRP_MJ_CLOSE. If that was the last file
close (no
more FOs in the list, Image and Data pointers are NULL), then I add a list
entry to
write to a log file.
A system thread would then check the list, and write out information
to all log
files it’s supposed to write to. I don’t wait on the thread to finish
processing
though.
If I let the OS run long enough (10 minutes I guess), the last close
occurs, the
log file is written to.
A purge during close MIGHT help, which I’ll try, but I believe this
can cause
deadlocks?

Regards, Dejan.

Peter Scott wrote:

> You indicate that you may be ‘getting the close too late to be able to
write
> to the file.’ I presume this is during shutdown processing and your
check is
> after reboot you see the data was not flushed correctly to the file in
> question.
>
> This does happen if you simply register for shutdown notification
through
> the IoRegxxx api. Since shutdown irps are not called in a ‘layered’
model,
> there is no deterministic way to say your shutdown routine will be
called
> before or after the shutdown for NTFS shutdown routine. Therefore your
> shutdown routine could be called after the NTFS driver and therefore
when
> you try and write out data it is failing.
>
> One way to check this is to hook the NTFS shutdown routine and see if it
is
> getting called before or after your driver’s shutdown routine. Again,
this
> would be only for diagnostics and not for actual production, as Tony
noted.

–
Kind regards, Dejan M. MVP for DDK
http://www.alfasp.com E-mail: xxxxx@alfasp.com
Alfa Transparent File Encryptor - Transparent file encryption services.
Alfa File Protector - File protection and hiding library for Win32
developers.
Alfa File Monitor - File monitoring library for Win32 developers.

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

OSR_Community_User · April 5, 2004, 8:01am

Ok, so I figured there’s no assurance a close will happen before the system shuts
down…
I have to revert to other methods:-)

–
Kind regards, Dejan M. MVP for DDK
http://www.alfasp.com E-mail: xxxxx@alfasp.com
Alfa Transparent File Encryptor - Transparent file encryption services.
Alfa File Protector - File protection and hiding library for Win32 developers.
Alfa File Monitor - File monitoring library for Win32 developers.