Archived from groups: microsoft.public.development.device.drivers,microsoft.public.windowsxp.device_driver.dev (
More info?)
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
--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.
"cristalink" <cristalink@nospam.nospam> wrote in message
news:ejO1%2314FFHA.3840@tk2msftngp13.phx.gbl...
> 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.
>
> --
>
http://www.firestreamer.com - NTBackup to DVD and DV
>
>
> "cristalink" <cristalink@nospam.nospam> wrote in message
> news:eA$%23AhwFFHA.3732@tk2msftngp13.phx.gbl...
>>> 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/default.asp?url=/library/en-us/kmarch/hh/kmarch/k113_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/default.asp?url=/library/en-us/kmarch/hh/kmarch/k113_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
>>
>> --
>>
http://www.firestreamer.com - NTBackup to DVD and DV
>>
>>
>> "Alexander Grigoriev" <alegr@earthlink.net> wrote in message
>> news:eo90#qvFFHA.3336@TK2MSFTNGP10.phx.gbl...
>>> 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" <cristalink@nospam.nospam> wrote in message
>>> news:es5XNjSFFHA.3664@TK2MSFTNGP15.phx.gbl...
>>> >>> is file object can be found at the same memory address
>>> >>> I mean file object 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.
>>> >
>>>
>>>
>>
>>
>>
>>
>
>
Facebook
Twitter
Instagram