If there is some logging/listening application that your driver is communicating with, things are simple. The application opens a file handle to your filter and like peter said, you can use the file object in each i/o to identify the process. The file object can ID the process until you get a IRP_MN_CLEANUP on the file object.
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Jakob Bohm
Sent: Tuesday, May 29, 2007 7:31 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Unique process/instance identifier
ferents@cs.bgu.ac.il wrote:
Hi ,
I need a way to distinguish between processes . i can’t use the
process ID (GetCurrentProcessID , PsGetCurrentProcessID) because
windows reuse the process IDs .
Of course, i can examine both process-ID and process-name, but it’s
not guaranteed to be correct as well : if process X is
started,terminated and starts again - it’s possible to get the same
process ID (same process ID for different instance…) .
I wonder if there’s a UUID/GUID for process creation . i don’t want
to use process-notify-callbacks to track processes, but i feel like i
have no choice…
All the kinds of process identifiers in Windows (handles, process ids,
EPROCESS pointers==KPROCESS pointers) are reused when no longer needed.
But you can delay the reuse of process ids and EPROCESS pointers by
holding an open handle (user mode) or object reference (kernel mode) on
the process object. As long as you hold one of those on a given
process, neither the process ID nor the EPROCESS pointer can be reused,
and the process statistics (such as execution time and exit code) remain
available through the usual interfaces.
So in a driver: Identify processes by EPROCESS, hold a reference on any
pointer values you save away for later comparison, and do remember to
free up those references once you no longer need them.
To test if a process has exited (so freeing up your reference on its
EPROCESS has at least some urgency): call KeWaitForSingleObject on it
with a 0 timeout. If it times out, the process is still running,
otherwise not.
And none of this really needs one of those expensive process callbacks.
P.S.
Please beware of the “arbitrary thread context” concept and its
implications.
–
Jakob B?hm, M.Sc.Eng. * xxxxx@danware.dk * direct tel:+45-45-90-25-33
Danware Data A/S * Bregnerodvej 127 * DK-3460 Birkerod * DENMARK
http://www.netop.com * tel:+45-45-90-25-25 * fax tel:+45-45-90-25-26
Information in this mail is hasty, not binding and may not be right
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer