PsPsSetCreateProcessNotifyRoutine - Any way to get more information?

Hello all,

My driver currently registers for create process notifications. I was
wondering though if there was a way to get more information besides
just the parent pid, the pid and whether it was created.

NTSTATUS PsSetCreateProcessNotifyRoutine(
__in PCREATE_PROCESS_NOTIFY_ROUTINE NotifyRoutine,
__in BOOLEAN Remove
);

VOID
(*PCREATE_PROCESS_NOTIFY_ROUTINE) (
IN HANDLE ParentId,
IN HANDLE ProcessId,
IN BOOLEAN Create
);

What I really need is how the process was created i.e. if it was
created on the command line, i need the full command-line path, if it
was created by explorer, give me the verb and the file that was
double-clicked etc. I’ve read something about the PEB, would this
help?

Is this possible?

Thanks,
J

>give me the verb and the file that was double-clicked etc

Well, this is surely impossible in the kernel. Try designing a shell extension for this.


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

Which Windows versions do you aim to support? If it’s only Vista SP1 and higher you can look at PsSetCreateProcessNotifyRoutineEx, it gives you information about the creator and the command line arguments and more.

Pre-Vista I only know of a way to get the Image file name, as far as I know there is no documented way to get stuff like the command line arguments.

Jonathon wrote:

My driver currently registers for create process notifications. I was
wondering though if there was a way to get more information besides
just the parent pid, the pid and whether it was created.

What I really need is how the process was created i.e. if it was
created on the command line, i need the full command-line path, if it
was created by explorer, give me the verb and the file that was
double-clicked etc. I’ve read something about the PEB, would this
help?

No. That information is not available, because it isn’t relevant. All
of the paths you mention, plus many other paths, eventually lead to a
call to CreateProcess. That’s what you are intercepting. The trigger
that led up to that call is just an implementation detail of the calling
process. It isn’t relevant to the operating system.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.