Why is IRP_MJ_CLOSE needed (when there is IRP_MJ_CLEANUP)?

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

From the WDK documentation for IRP_MJ_CLEANUP:

"Receipt of the IRP_MJ_CLEANUP request indicates that the *handle*
reference count on a file object has reached zero."

From the WDK documentation for IRP_MJ_CLOSE:

"Receipt of the IRP_MJ_CLOSE request indicates that the reference
count on a file object has reached zero."

Is the difference abvoe between "handle reference count" and
"reference count" meaningful? If so, what does that mean?

OK, so I read on and the the WDK documentation for IRP_MJ_CLEANUP
says:

"Often it is sent when a user-mode application has called the
Microsoft Win32 CloseHandle function (or when a kernel-mode driver has
called ZwClose) on the last outstanding handle to a file object."

How confusing: a call to CloseHandle() does not translate into
IRP_MJ_CLOSE but rather into IRP_MJ_CLEANUP. Why is that?

The WDK documentation for IRP_MJ_CLOSE, on the other hand, reads:

"usually because a file system driver or other kernel-mode component
has called ObDereferenceObject on the file object."

OK, so I understand that while IRP_MJ_CLEANUP is guaranteed to be sent
in the context of the process that created the handle, IRP_MJ_CLOSE
can come in *any* context, including the system context after the
process has exited.

But... the WDK documentation for IRP_MJ_CLOSE, continues:

"This request normally follows a cleanup request. However, this does
not necessarily mean that the close request will be received
immediately after the cleanup request."

So, Is IRP_MJ_CLEANUP *always* followed by a IRP_MJ_CLOSE (even if not
"immediately")? What does "immediately" in the above context means?

My observation, using WinDbg on a driver that I develop, suggests that
the answer is "Yes" - IRP_MJ_CLEANUP is *always* followed by a
IRP_MJ_CLOSE. But this doesn't make sense: why two IRPs for the same
thing? What am I supposed to do in response to IRP_MJ_CLOSE if I
already handle IRP_MJ_CLEANUP?

What am I missing?

Thanks,
Don

.

Relevant Pages

  • Re: file object address
    ... once the ref count has gone to zero, ... > - MJ_CLOSE seems to be sent when the reference count to the FILE_OBJECT is ... ObReferenceObject on the FILE_OBJECT seems to produce ... >> reference to the file object during MJ_CLOSE, ...
    (microsoft.public.development.device.drivers)
  • Re: file object address
    ... once the ref count has gone to zero, ... > - MJ_CLOSE seems to be sent when the reference count to the FILE_OBJECT is ... ObReferenceObject on the FILE_OBJECT seems to produce ... >> reference to the file object during MJ_CLOSE, ...
    (microsoft.public.windowsxp.device_driver.dev)
  • Re: file object address
    ... > MJ_CLOSE is sent at the moment the reference count is about to drop to ... zero. ... the file object that is associated with the target device object ****has ... >> From my point of view, you obviously asked about the file object *memory ...
    (microsoft.public.development.device.drivers)
  • Re: file object address
    ... > MJ_CLOSE is sent at the moment the reference count is about to drop to ... zero. ... the file object that is associated with the target device object ****has ... >> From my point of view, you obviously asked about the file object *memory ...
    (microsoft.public.windowsxp.device_driver.dev)
  • Re: file object address
    ... - MJ_CLOSE seems to be sent when the reference count to the FILE_OBJECT is ... "about to drop to zero" ... memory on Win2k3 with changing the object type to 'bad'. ... even when one have a valid file object to reference. ...
    (microsoft.public.windowsxp.device_driver.dev)