file object address

[Alex]

Can I rely on the file object address in my file system filter driver during
all the life-time of the object? In other words, is file object can be
found at the same memory address during all the life-time till the last
close operation?

 

[cristalink]

Yes, as long you maintain the reference counter. Depending on where you get
the file object from, it may or may not have the counter incremented. For
instance, for IRP's one, you need to call
ObReferenceObject/ObDereferenceObject. For an object obtained with
ObReferenceObjectByHandle, you need to call ObDereferenceObject only.

 

[Maxim S. Shatskih]

FILE_OBJECT is valid till MJ_CLOSE will go for it. You cannot miss
MJ_CLOSE.

instance, for IRP's one, you need to call
ObReferenceObject/ObDereferenceObject.

I would never do this. When do you suggest to dereference in this approach?

 

[cristalink]

I do not suggest to dereference anything. I just pointed out that the
reference counter of FILE_OBJECT in IRP is maintained by Windows. So if
somebody for whatever reason, whether right or not, wants to access the
FILE_OBJECT after the IRP is completed, then they need to Reference the
object first and then Dereference it when finished.

 

[Alex]

Thank you, Maxim.

FILE_OBJECT is valid till MJ_CLOSE will go for it. You cannot miss
MJ_CLOSE.


I would never do this. When do you suggest to dereference in this approach?

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
(e-mail address removed)
http://www.storagecraft.com

 

[Alex]

Thanks
Of course, I know that reference to object is important. I mean file object
address inside operations on this file object, I told about fs filter
driver.

 

[cristalink]

is file object can be found at the same memory address
From my point of view, you obviously asked about the file object *memory
address*. I am sorry, but my magic crystal ball didn't tell me you know
about reference counters.

In fact, the address of a FILE_OBJECT and the validity of the memory at this
address do not depend on MJ_CLOSE, as it was said before. Even after
MJ_CLOSE the file object remains valid until the reference counter drops to
zero. If you ObReference'd a file object and didn't call ObDereferenceObject
on it, the file object remains a valid piece of memory until you switched
your computer off.

MJ_CLOSE just means the last handle to the file is closed. The file handle
is not the same as the file object.

 

[Alexander Grigoriev]

MJ_CLOSE is sent at the moment the reference count is about to drop to zero.

When the last handle is closed, MJ_CLEANUP is sent, not MJ_CLOSE.

 

[cristalink]

MJ_CLOSE is sent at the moment the reference count is about to drop to
zero.

Very interesting concept... So you are saying that if I took an additional
reference to the file object during MJ_CLOSE, and then dereferenced it
somewhen later, I would get another MJ_CLOSE?

If you meant the reference count of the last handle (which I highly doubt,
sorry), then what does your remark have to do with the discussion about
FILE_OBJECT?

When the last handle is closed, MJ_CLEANUP is sent, not MJ_CLOSE.

Right... Let's see what DDK says.

http://msdn.microsoft.com/library/d..._b0a0adfc-46dc-4da2-aed2-826a0b46d00a.xml.asp

IRP_MJ_CLEANUP (***cleaning up***)
When Sent: Receipt of this request indicates that the last handle for a file
object that is associated with the target device object has been closed
(but, due to outstanding I/O requests, ****might not have been released***).

http://msdn.microsoft.com/library/d..._bb864c28-6a78-4158-be96-f03e6e23dc74.xml.asp

IRP_MJ_CLOSE (***closing***)
When Sent: Receipt of this request indicates that ***the last handle*** of
the file object that is associated with the target device object ****has
been closed and released***. All outstanding I/O requests have been
completed or canceled.

I seem to be the only one among the contributors to this thread who
understands the concept of FILE_OBJECT reference counters

 

[Thomas F. Divine [DDK MVP]]

zero.

Very interesting concept... So you are saying that if I took an additional
reference to the file object during MJ_CLOSE, and then dereferenced it
somewhen later, I would get another MJ_CLOSE?

If you meant the reference count of the last handle (which I highly doubt,
sorry), then what does your remark have to do with the discussion about
FILE_OBJECT?


Right... Let's see what DDK says.

http://msdn.microsoft.com/library/d..._b0a0adfc-46dc-4da2-aed2-826a0b46d00a.xml.asp

IRP_MJ_CLEANUP (***cleaning up***)
When Sent: Receipt of this request indicates that the last handle for a
file
object that is associated with the target device object has been closed
(but, due to outstanding I/O requests, ****might not have been
released***).

http://msdn.microsoft.com/library/d..._bb864c28-6a78-4158-be96-f03e6e23dc74.xml.asp

IRP_MJ_CLOSE (***closing***)
When Sent: Receipt of this request indicates that ***the last handle*** of
the file object that is associated with the target device object ****has
been closed and released***. All outstanding I/O requests have been
completed or canceled.

I seem to be the only one among the contributors to this thread who
understands the concept of FILE_OBJECT reference counters

I think that the confusion is because there are two separate counters:
handle count and reference count. See the DDK Topic "Errors in Handling
Cleanup and Close Operations""

"Some drivers fail to distinguish the tasks required in DispatchCleanup and
DispatchClose routines. The I/O Manager calls a driver's DispatchCleanup
routine when the last handle to a file object is closed. The DispatchClose
routine is called when the last reference is released from the file object.
A driver should not attempt to free resources in its DispatchCleanup routine
that are attached to a file object or might be used by other Dispatch
routines.
When calling dispatch routines, the I/O Manager holds a reference to the
file object for normal I/O calls. As a result, a driver can receive I/O
requests for a file object after its DispatchCleanup routine has been called
but before its DispatchClose routine is called. For example, a user-mode
caller might close the file handle while an I/O Manager request is in
progress from another thread. If the driver has deleted or freed necessary
resources before the I/O Manager calls its DispatchClose routine, invalid
pointer references and other problems could occur. "


Thomas F. Divine, Windows DDK MVP.
http://www.pcausa.com

 

[cristalink]

Alexander,

You seem to be right about MJ_CLOSE and I was wrong. My sincere apologies...

I've made some tests with the below results.

- MJ_CLOSE doesn't seem to be sent if there's an extra reference to the
FILE_OBJECT

- MJ_CLOSE seems to be sent when the reference count to the FILE_OBJECT is
"about to drop to zero"

- Inside MJ_CLOSE, ObReferenceObject on the FILE_OBJECT seems to produce
different results on XP and Win2k3. As far as I can tell with a local
debugger, ObReferenceObject is ignored on XP, but seems to preserve the
memory on Win2k3 with changing the object type to 'bad'. XP's behaviour
doesn't seem correct to me, as it makes ObReferenceObject unsafe to use in
certain circumstances, even when one have a valid file object to reference.
On the other hand, MJ_CLOSE for FILE_OBJECT seems to be something like a
destructor for a COM object. AddRef() is a wrong thing to call when the
object is being destroyed.

 

[Doron Holan [MS]]

exactly right. once the ref count has gone to zero, incrementing it leads
to undefined behavior. calling ObReferenceObject on the fileobject being
closed in IRP_MJ_CLOSE is undefined.

d

 

[Maxim S. Shatskih]

address do not depend on MJ_CLOSE, as it was said before. Even after

MJ_CLOSE the file object remains valid until the reference counter drops to

It occurs immediately. When the refcount drops to zero, MJ_CLOSE is called, and
just after this the file object is freed. In C++ term, MJ_CLOSE is destructor.

Do not mix with MJ_CLEANUP.