Sign in with
Sign up | Sign in
Your question

file object address

Tags:
  • Drivers
  • Microsoft
  • Device Driver
  • Windows XP
Last response: in Windows XP
Share
February 17, 2005 12:50:51 AM

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?

More about : file object address

Anonymous
a b \ Driver
February 17, 2005 11:16:13 AM

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?
>
>
Anonymous
a b \ Driver
February 17, 2005 11:16:14 AM

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
Related resources
Anonymous
a b \ Driver
February 17, 2005 4:05:42 PM

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
>
>
February 17, 2005 6:57:53 PM

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
>
>
February 17, 2005 7:06:50 PM

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
> >
> >
>
>
Anonymous
a b \ Driver
February 18, 2005 11:42:21 AM

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
>> >
>> >
>>
>>
>
>
Anonymous
a b \ Driver
February 19, 2005 10:17:41 PM

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.
>
Anonymous
a b \ Driver
February 20, 2005 8:54:23 PM

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=/libr...

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=/libr...

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.
> >
>
>
Anonymous
a b \ Driver
February 20, 2005 8:54:24 PM

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=/libr...
>
> 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=/libr...
>
> 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.
>> >
>>
>>
>
>
>
>
Anonymous
a b \ Driver
February 21, 2005 12:48:11 PM

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=/libr...
>
> 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=/libr...
>
> 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.
>> >
>>
>>
>
>
>
>
Anonymous
a b \ Driver
February 21, 2005 9:48:07 PM

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=/libr...
>>
>> 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=/libr...
>>
>> 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.
>>> >
>>>
>>>
>>
>>
>>
>>
>
>
Anonymous
a b \ Driver
February 23, 2005 9:15:33 AM

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
!