PsSetCreateProcessNotifyRoutine

以下讨论限于win2k，nt,xp我还没做实验。

ddk是这么说的：

The driver's process-creation notify routine runs at IRQL PASSIVE_LEVEL, either in the context of the initial thread within a newly created process or in the context of a system thread.

实验表明，几乎没有运行system thread context（system process）的情况。

当create=true的时候，都是运行在parent process context下――
注意并非newly created process context。
当create=false的时候，运行在current process下。


这个函数是串行的。该notifyroutine不返回，新process不会开始。
此外，如果在这里（核心）加载一个dll，那么不等到dll process_attach返回，不会返回。新process不会运行。

我看了一下2000的源代码，发现当进程的第一个线程建立时，这时候进程的标识号还没有确定，系统就顺便调用OpCreateHandle()建立一个句柄并把这个句柄赋值给EProcess->UniqueProcessId变量，然后开始扫描回调例程表并进行调用。

if(进程号还没有确定？）
{
1、分配进程号。
2、调用进程建立通知回调例程。
}

很明显，当我们的驱动调用PsSetCreateProcessNotifyRoutine()这个例程的时候，System.exe一般都已经启动了，也就是说System.exe的第一个线程在我们调用这个例程之前就已经启动了。所以我们永远不会探测到System.exe进程地建立，我们的回调例程当然也就永远不可能运行在System Context下面了。

在老大面前班门弄斧，见笑了。

我看了一下2000的源代码，发现当进程的第一个线程建立时，这时候进程的标识号还没有确定，系统就顺便调用OpCreateHandle()建立一个句柄并把这个句柄赋值给EProcess->UniqueProcessId变量，然后开始扫描回调例程表并进行调用。

if(进程号还没有确定？）
{
1、分配进程号。
2、调用进程建立通知回调例程。
}

很明显，当我们的驱动调用PsSetCreateProcessNotifyRoutine()这个例程的时候，System.exe一般都已经启动了，也就是说System.exe的第一个线程在我们调用这个例程之前就已经启动了。所以我们永远不会探测到System.exe进程地建立，我们的回调例程当然也就永远不可能运行在System Context下面了。

在老大面前班门弄斧，见笑了。

无论如何，此处都只可能是父进程的context。
在某个system thread上直接创建一个process，也许在system
process context下面。

要得到该进程最早的context，必须hook ldrinitializethunk。
这个函数是一个用户态函数，必须在子process的context下执行。
系统创建进程，初始化了半天，最后启动一个APC，把
ldrinitializethunk插入队列，等待调度，该函数调用
LdrpInitialize ，LdrpInitialize 调用LdrpInitializeProcess ，
在用户态把该加载的都加载了，把静态连接的dll都
dll_process_attach了，然后进入到run_time库的入口地址。

shit，我发现直接看src，还不如仔细看inside win2k。
看了半天src，才发现inside win2k已经说得很清楚。

PsSetCreateThreadNotifyRoutine
设置的threadcallback函数运行的precess context为父线程的。

如果是system thread就是system process(8),
如果是一个新process，就是父进程
如果是自己createthread，就是自己。