KeDelayExecutionThread in PsSetCreateProcessNotifyRoutine callback
in [Win32 Kernel]
|
Prev: Overlapped IO Fail with Error 995 i.e. ERROR_OPERATION_ABORTED
Next: KeDelayExecutionThread in PsSetCreateProcessNotifyRoutine
From: ceh on 24 Mar 2010 08:56 Hi, please be aware that this is academic. I have a driver that aggregates a list of pids via the PsSetCreateProcessNotifyRoutine callback. The pid list is copied back to user space via DeviceIoControl When a new process is created, I'm notified in the callback and I have to protect an internal array of these pids. To do this I have something like the following in my callback in the driver. .... ExAcquireFastMutex( &g_Mutex ); .... modify internal array .... ExReleaseFastMutex( &g_Mutex ); It all works fine, but I'm trying to better understand what is going on in the following scenario. If I mimic a lot of work in that area, for example the following with an 8 second delay in li. .... ExAcquireFastMutex( &g_Mutex ); .... KeDelayExecutionThread( KernelMode, FALSE, &li ); .... ExReleaseFastMutex( &g_Mutex ); Then no other processes on the machine will be allowed to run until after the 8 seconds elapses. http://msdn.microsoft.com/en-us/library/ms802952.aspx states: ...when a process is created, the process-notify routine runs in the context of the thread that created the new process I'm assuming here that "the thread that created the new process" IS: some thread running in some _secret_ system component, that I potentially can't see via something like taskmgr and that that component is responsible for creating all processes on the system and that at this time, that thread is waiting for the time to elapse. So, the questions are: 1. Where is the thread that created the new process? Meaning... what process is that thread in? 2. How does DeviceIoControl in some usermode process call into a different process? 3. If I have n hooks in my PsSetCreateProcessNotifyRoutine list, will any subsequent ones run, or do they have to wait here as well? 3. Am I wrong on anything here? 4. Does the newer PsSetCreateProcessNotifyRoutineEx behave the same? Thanks for any insights.
From: Don Burn on 24 Mar 2010 09:18 The thread that creates the new process is the thread that called CreateProcess in user space. IoControl calls do not call into a process they call into the kernel which is shared by all processes. The PsSetCreateProcessNotifyRoutine callbacks are on a queue (limited in size by the way so do not put in multiple callbacks), and a called one after another by the thread creating the new process. Most of your assumptions are way off. Don Burn (MVP, Windows DKD) Windows Filesystem and Driver Consulting Website: http://www.windrvr.com Blog: http://msmvps.com/blogs/WinDrvr > -----Original Message----- > From: ceh [mailto:cehupper(a)gmail.com] > Posted At: Wednesday, March 24, 2010 8:56 AM > Posted To: microsoft.public.win32.programmer.kernel > Conversation: KeDelayExecutionThread in PsSetCreateProcessNotifyRoutine > callback > Subject: KeDelayExecutionThread in PsSetCreateProcessNotifyRoutine callback > > Hi, please be aware that this is academic. > > I have a driver that aggregates a list of pids via the > PsSetCreateProcessNotifyRoutine callback. > The pid list is copied back to user space via DeviceIoControl > > When a new process is created, I'm notified in the callback and I have to > protect an internal array of these pids. > To do this I have something like the following in my callback in the driver. > > ... > ExAcquireFastMutex( &g_Mutex ); > ... > modify internal array > ... > ExReleaseFastMutex( &g_Mutex ); > > It all works fine, but I'm trying to better understand what is going on in the > following scenario. > > If I mimic a lot of work in that area, for example the following with an 8 > second delay in li. > > ... > ExAcquireFastMutex( &g_Mutex ); > ... > KeDelayExecutionThread( KernelMode, FALSE, &li ); ... > ExReleaseFastMutex( &g_Mutex ); > > Then no other processes on the machine will be allowed to run until after the > 8 seconds elapses. > > http://msdn.microsoft.com/en-us/library/ms802952.aspx > states: ...when a process is created, the process-notify routine runs in the > context of the thread that created the new process > > I'm assuming here that "the thread that created the new process" IS: > some thread running in some _secret_ system component, that I potentially > can't see via something like taskmgr and that > that component is responsible for creating all processes on the system > and that > at this time, that thread is waiting for the time to elapse. > > So, the questions are: > 1. Where is the thread that created the new process? Meaning... what process > is that thread in? > 2. How does DeviceIoControl in some usermode process call into a different > process? > 3. If I have n hooks in my PsSetCreateProcessNotifyRoutine list, will any > subsequent ones run, or do they have to wait here as well? > 3. Am I wrong on anything here? > 4. Does the newer PsSetCreateProcessNotifyRoutineEx behave the same? > > Thanks for any insights. > > > __________ Information from ESET Smart Security, version of virus signature > database 4970 (20100324) __________ > > The message was checked by ESET Smart Security. > > http://www.eset.com >
From: ceh on 24 Mar 2010 09:44
On Mar 24, 9:18 am, "Don Burn" <b...(a)stopspam.windrvr.com> wrote: > The thread that creates the new process is the thread that called > CreateProcess in user space. IoControl calls do not call into a process > they call into the kernel which is shared by all processes. The > PsSetCreateProcessNotifyRoutine callbacks are on a queue (limited in > size by the way so do not put in multiple callbacks), and a called one > after another by the thread creating the new process. > > Most of your assumptions are way off. > > Don Burn (MVP, Windows DKD) > Windows Filesystem and Driver Consulting > Website:http://www.windrvr.com > Blog:http://msmvps.com/blogs/WinDrvr > > > -----Original Message----- > > From: ceh [mailto:cehup...(a)gmail.com] > > Posted At: Wednesday, March 24, 2010 8:56 AM > > Posted To: microsoft.public.win32.programmer.kernel > > Conversation: KeDelayExecutionThread in > > PsSetCreateProcessNotifyRoutine > > > > > callback > > Subject: KeDelayExecutionThread in PsSetCreateProcessNotifyRoutine > callback > > > Hi, please be aware that this is academic. > > > I have a driver that aggregates a list of pids via the > > PsSetCreateProcessNotifyRoutine callback. > > The pid list is copied back to user space via DeviceIoControl > > > When a new process is created, I'm notified in the callback and I have > to > > protect an internal array of these pids. > > To do this I have something like the following in my callback in the > driver. > > > ... > > ExAcquireFastMutex( &g_Mutex ); > > ... > > modify internal array > > ... > > ExReleaseFastMutex( &g_Mutex ); > > > It all works fine, but I'm trying to better understand what is going > on in the > > following scenario. > > > If I mimic a lot of work in that area, for example the following with > an 8 > > second delay in li. > > > ... > > ExAcquireFastMutex( &g_Mutex ); > > ... > > KeDelayExecutionThread( KernelMode, FALSE, &li ); ... > > ExReleaseFastMutex( &g_Mutex ); > > > Then no other processes on the machine will be allowed to run until > after the > > 8 seconds elapses. > > >http://msdn.microsoft.com/en-us/library/ms802952.aspx > > states: ...when a process is created, the process-notify routine runs > in the > > context of the thread that created the new process > > > I'm assuming here that "the thread that created the new process" IS: > > some thread running in some _secret_ system component, that I > potentially > > can't see via something like taskmgr and that > > that component is responsible for creating all processes on the > system > > and that > > at this time, that thread is waiting for the time to elapse. > > > So, the questions are: > > 1. Where is the thread that created the new process? Meaning... what > process > > is that thread in? > > 2. How does DeviceIoControl in some usermode process call into a > different > > process? > > 3. If I have n hooks in my PsSetCreateProcessNotifyRoutine list, will > any > > subsequent ones run, or do they have to wait here as well? > > 3. Am I wrong on anything here? > > 4. Does the newer PsSetCreateProcessNotifyRoutineEx behave the same? > > > Thanks for any insights. > > > __________ Information from ESET Smart Security, version of virus > signature > > database 4970 (20100324) __________ > > > The message was checked by ESET Smart Security. > > >http://www.eset.com I'm trying to learn here. That is all. "The thread that creates the new process is the thread that called CreateProcess in user space" If I'm a cmd.exe process and I call createprocess then you're saying that some thread in cmd.exe is the thread that the notifyroutine is running in? If that is true, then why do all process creations freeze across the system if there is a wait in the notifyroutine? Shouldn't only that one thread be blocked? "IoControl calls do not call into a process they call into the kernel which is shared by all processes" Is this saying that the kernel is just some section of memory not associated with any specific process? I'm aware of the queue limit. Thanks. |