file object address

Archived from groups: microsoft.public.development.device.drivers,microsoft.public.windowsxp.device_driver.dev (More info?)

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?
12 answers Last reply
More about file object address
  1. Archived from groups: microsoft.public.development.device.drivers,microsoft.public.windowsxp.device_driver.dev (More info?)

    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.

    --
    http://www.firestreamer.com - NTBackup to DVD and DV


    "Alex" <wint69@pisem.net> wrote in message
    news:uZaE6ZFFFHA.732@TK2MSFTNGP12.phx.gbl...
    > 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?
    >
    >
  2. Archived from groups: microsoft.public.development.device.drivers,microsoft.public.windowsxp.device_driver.dev (More info?)

    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?

    --
    Maxim Shatskih, Windows DDK MVP
    StorageCraft Corporation
    maxim@storagecraft.com
    http://www.storagecraft.com
  3. Archived from groups: microsoft.public.development.device.drivers,microsoft.public.windowsxp.device_driver.dev (More info?)

    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.

    --
    http://www.firestreamer.com - NTBackup to DVD and DV


    "Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
    news:e97HgFIFFHA.3972@TK2MSFTNGP15.phx.gbl...
    > 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?
    >
    > --
    > Maxim Shatskih, Windows DDK MVP
    > StorageCraft Corporation
    > maxim@storagecraft.com
    > http://www.storagecraft.com
    >
    >
  4. Archived from groups: microsoft.public.development.device.drivers,microsoft.public.windowsxp.device_driver.dev (More info?)

    Thank you, Maxim.

    "Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
    news:e97HgFIFFHA.3972@TK2MSFTNGP15.phx.gbl...
    > 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?
    >
    > --
    > Maxim Shatskih, Windows DDK MVP
    > StorageCraft Corporation
    > maxim@storagecraft.com
    > http://www.storagecraft.com
    >
    >
  5. Archived from groups: microsoft.public.development.device.drivers,microsoft.public.windowsxp.device_driver.dev (More info?)

    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" <cristalink@nospam.nospam> wrote in message
    news:e9ZEtRIFFHA.3368@TK2MSFTNGP10.phx.gbl...
    > 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.
    >
    > --
    > http://www.firestreamer.com - NTBackup to DVD and DV
    >
    >
    > "Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
    > news:e97HgFIFFHA.3972@TK2MSFTNGP15.phx.gbl...
    > > 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?
    > >
    > > --
    > > Maxim Shatskih, Windows DDK MVP
    > > StorageCraft Corporation
    > > maxim@storagecraft.com
    > > http://www.storagecraft.com
    > >
    > >
    >
    >
  6. Archived from groups: microsoft.public.development.device.drivers,microsoft.public.windowsxp.device_driver.dev (More info?)

    >> 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.

    --
    http://www.firestreamer.com - NTBackup to DVD and DV


    "Alex" <wint69@pisem.net> wrote in message
    news:%23GuYo9OFFHA.1348@TK2MSFTNGP14.phx.gbl...
    > 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" <cristalink@nospam.nospam> wrote in message
    > news:e9ZEtRIFFHA.3368@TK2MSFTNGP10.phx.gbl...
    >> 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.
    >>
    >> --
    >> http://www.firestreamer.com - NTBackup to DVD and DV
    >>
    >>
    >> "Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
    >> news:e97HgFIFFHA.3972@TK2MSFTNGP15.phx.gbl...
    >> > 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?
    >> >
    >> > --
    >> > Maxim Shatskih, Windows DDK MVP
    >> > StorageCraft Corporation
    >> > maxim@storagecraft.com
    >> > http://www.storagecraft.com
    >> >
    >> >
    >>
    >>
    >
    >
  7. Archived from groups: microsoft.public.development.device.drivers,microsoft.public.windowsxp.device_driver.dev (More info?)

    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.
    >
  8. Archived from groups: microsoft.public.development.device.drivers,microsoft.public.windowsxp.device_driver.dev (More info?)

    > 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.
    > >
    >
    >
  9. Archived from groups: microsoft.public.development.device.drivers,microsoft.public.windowsxp.device_driver.dev (More info?)

    "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 :)
    >
    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

    > --
    > 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.
    >> >
    >>
    >>
    >
    >
    >
    >
  10. Archived from groups: microsoft.public.development.device.drivers,microsoft.public.windowsxp.device_driver.dev (More info?)

    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.
    >> >
    >>
    >>
    >
    >
    >
    >
  11. 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.
    >>> >
    >>>
    >>>
    >>
    >>
    >>
    >>
    >
    >
  12. Archived from groups: microsoft.public.development.device.drivers,microsoft.public.windowsxp.device_driver.dev (More info?)

    > 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.

    --
    Maxim Shatskih, Windows DDK MVP
    StorageCraft Corporation
    maxim@storagecraft.com
    http://www.storagecraft.com
Ask a new question

Read More

Drivers Microsoft Device Driver Windows XP