CreateFile / CloseHandle

Hey guys,

in the context of a mini filter IRP_MJ_CLEANUP and IRP_MJ_CLOSE irps only show up when the handle count or the reference count of a file object has reached zero. These callbacks are then in any or the system context.

I need to track which process calls “CloseHandle” on file objects. How could i achieve this?

Hi,

You can track down the requestor process for the IRP_MJ_CLEANUP, which is called at the time the last handle for a given file has been closed, using the FltGetRequestorProcess routine.

http://msdn.microsoft.com/en-us/library/windows/hardware/ff543115(v=vs.85).aspx

Regards,

Fernando Roberto da Silva
DriverEntry Kernel Development
http://www.DriverEntry.com.br

Hi Fernando,

yea but the handle can be opened by many processes when it was not opened exclusively. With the IRP_MJ_CLEANUP i can only get the last process which is closing it.

Can i achieve to track every process closing the handle?

You can’t really do that with a file system filter, there is no notification sent by the IO manager when a process closes a handle that is not the last handle for the FILE_OBJECT.

Thanks,
Alex.

Sent from my iPhone

On Aug 13, 2012, at 10:02 PM, xxxxx@hotmail.de wrote:

Hi Fernando,

yea but the handle can be opened by many processes when it was not opened exclusively. With the IRP_MJ_CLEANUP i can only get the last process which is closing it.

Can i achieve to track every process closing the handle?


NTFSD is sponsored by OSR

For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Okay although it’s off topic here. Is there a “official” way ( i don’t want to use hooking or not documented ways ) for tracking CloseHandle calls in a different stack than the mini filter’s?

If many processes open the file/stream you will have many file objects
resulting in many cleanups.

Bill Wandel

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.de
Sent: Monday, August 13, 2012 4:02 PM
To: Windows File Systems Devs Interest List
Subject: RE:[ntfsd] CreateFile / CloseHandle

Hi Fernando,

yea but the handle can be opened by many processes when it was not opened
exclusively. With the IRP_MJ_CLEANUP i can only get the last process which
is closing it.

Can i achieve to track every process closing the handle?


NTFSD is sponsored by OSR

For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Hi Bill Wandel,

so every CreateFile call ( even on the same file or not ) will create a new file object? how are things like share rights solved then?

First, rights are managed by the file system, so the file system mediates
sharing. I have always acceped “Magic” as the right explanation.

However, CreateFile is not the only way handles come into existence.
DuplicateHandle creates /another/ handle, which must also be closed
byCloseHandle. But this handle /shares/ the FileObject, so a single
FileObject can have multiple handles. There is an implicit
DuplicateHandle which takes care of handle inheritance. So for ever
CreateFile call, there are a potentially very large number of CloseHandle
calls.

Then there’s the issue that CloseHandle closed all kinds of handles:
thread handles, process handles, mutex handles, semaphore hadles, and
event handles, and that all these handles can be duplicated or inherited
(this list is not mean to be exhaustive; there are many other kinds of
handles, and not all objects of type HANDLE are closed with CloseHandle,
but I think you can safely ignore those.

But measuring handle lifetime from create-to-close is not going to tell
you what you think; for example, pipe handles to a child process may
appear to have an extremely short lifetime, but you are seeing only half
the problem (a handle represents just one end of a pipe), and you have to
be cocerned with the inherited handles to get a good idea of the lifetime.

Consider this program, count.c

void main()
{
int i;
for(i = 1; i > 0; i++)
printf(“%d\n”, i);
}

which should print out all the positive integers from 1 to 2.4…G (ok,
it’s sloppy programming, but I wanted a trivial example). If I invoke it
as

count > data.txt

Then the shell has a CreateFile/CloseHandle lifetime of something
conveniently measured in milliseconds, but the file object (accessed via
the inherited handle) has a lifetime (and somebody else can do the math
here) conveniently measured in days or weeks, or maybe even months. Make
that a LONGLONG and the units are millenia (I can tell that one easily).
So CreateFile and CloseHandle are irrelevant. You would want to measure
the time from an IRP_MJ_CREATE to an IRP_MJ_CLOSE.
joe

Hi Bill Wandel,

so every CreateFile call ( even on the same file or not ) will create a
new file object? how are things like share rights solved then?


NTFSD is sponsored by OSR

For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

No, you could potentially have many CreateFile calls from a single
process; multiple processes are not a requirement. And don’t forget the
effects of DuplicateHandle and inheritance.
joe

If many processes open the file/stream you will have many file objects
resulting in many cleanups.

Bill Wandel

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.de
Sent: Monday, August 13, 2012 4:02 PM
To: Windows File Systems Devs Interest List
Subject: RE:[ntfsd] CreateFile / CloseHandle

Hi Fernando,

yea but the handle can be opened by many processes when it was not opened
exclusively. With the IRP_MJ_CLEANUP i can only get the last process which
is closing it.

Can i achieve to track every process closing the handle?


NTFSD is sponsored by OSR

For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer


NTFSD is sponsored by OSR

For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Hi Joseph M. Newcomer,

first of all thanks for the excellent explanation and for those examples.
So CreateFile calls ALWAYS end up in an new file object and if a handle is not duplicated or inherited the first CloseHandle call will cause an IRP_MJ_CLEANUP - is this correct?

Thanks for the adivce due to time measuring.

> So CreateFile calls ALWAYS end up in an new file object and if a handle is not duplicated or

inherited the first CloseHandle call will cause an IRP_MJ_CLEANUP - is this correct?

Yes.


Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

The cleanup request comes when the file object is a candidate for release.
So the rule is that whatever CloseHandle reduces the handle count to zero
triggers the cleanup request. Since you have no control over duplication
and inheritance, you have to assume they can occur.
joe

Hi Joseph M. Newcomer,

first of all thanks for the excellent explanation and for those examples.
So CreateFile calls ALWAYS end up in an new file object and if a handle is
not duplicated or inherited the first CloseHandle call will cause an
IRP_MJ_CLEANUP - is this correct?

Thanks for the adivce due to time measuring.


NTFSD is sponsored by OSR

For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer