Re[2]: is PEPROCESS unique for a process if in kernel?

To add to Tony’s comment, you can store off the Process Id in the
process create notification callback, for the parent and the process
being created. Then in your open callback retrieve the process id using
PsGetCurrentProcessId(). A parent and child process will have different
file objects for each open, they can share a handle to a given open
(file object) but each would have a unique file object if they each
opened the file.

You indicate you call PsGetCurrentProcess() from the process create
notification callback. Note that the calling process which invokes the
process create callback can be different than the true parent or child
process, for example when elevated privilege is required to launch a
process. So rely on the Parent and Process Ids in the structure passed
into the callback, and not necessarily the context the callback is
invoked in. Unless, of course, you want to know the context the callback
is invoked in. Using the Process Ids, along with tracking process
termination, as Tony mentioned, will provide you a mechanism to track
all (except for the system process) Process Ids which may call into your
open/create callback.


Kernel Drivers
Windows File System and Device Driver Consulting

------ Original Message ------
To: “Windows File Systems Devs Interest List”
Sent: 7/30/2016 10:13:27 PM
Subject: RE:[ntfsd] is PEPROCESS unique for a process if in kernel?

>Writing again as there were saome mistakes made in hurry.
>I am writing mini fsfilter driver where I make my metadata
>initialization only when open is called from particular process.
>I registered for process notification and save process id internally…
>When open is called, I match process id and get my metadata
>However sometime open comes from parent process ( Parent id in proc
>notification handler) and I miss that open.
>Can Parent and child process share FILE_OBJECT?
>PsSetCreateProcessNotifyRoutineEx says that parentid and processid both
>identify unique process.
>So I save PEPROCESS generated during PsGetCurrentProcess in
>notification call back and compare with PEPROCESS generated in open. If
>one of (process id or PEPROCESS) matches, I assume it is called from my
>Is assumption of PEPROCESS being unique is correct?
>NTFSD is sponsored by OSR
>MONTHLY seminars on crash dump analysis, WDF, Windows internals and
>software drivers!
>Details at http:
>To unsubscribe, visit the List Server section of OSR Online at

> Can Parent and child process share FILE_OBJECT?

Surely yes.

This is handle inheritance.

If you use:

myprog.exe > t.txt

then “cmd.exe” (the parent) opens t.txt, and “myprog.exe” (child) inherits the handle.

Maxim S. Shatskih
Microsoft MVP on File System And Storage

Thanks Tony.
I would forget this address once process terminates. Is there any way i can save some context with process on notification so that I can get same context when open comes? This will be a good solution for my problem.

Thanks Tony,
I can forget the EPROCESS address when process is getting terminated and address must be valid til process termination occurs. Is there any way, I can add context to process so that same context can be accessed when open is being called?

Sorry for posting twice :(.
Thanks Pete and Maxim,
Yes I do have a linked list which stores process id and if open calls’s process id matches then I do my work . However, I found out that in some scenario, Parent opens up File object, but IOs are received from actual process id I got in notification. So I miss the Open part hence can hook onto IOs. ( Same as pointed out by Maxim)

Exact scenario .
I hook onto a.exe and save its process id. It’s parent is b.exe. Normally open and IO both are from a.exe but in some scenario, Open comes from b.exe and IO comes from a.exe. My whole logic is based on detecting a.exe’s process id.

Pete, I agree to your point but if I use PsLookupProcessByProcessId on process notification for child process id and save it along with process id. then Is it fine to compare PEPROCESS?