Arun Kishan - Process Management in Windows Vista

The Discussion

• 

  Great video! I loved how everything was explained in such detail
  
  Good stuff

• 

  Thanks for yet another great Going Deep video! I am however, a little confused about one of the points in the video: I wonder if someone could be as kind as to clarify how exactly a TerminateThread call causes any kernel mode calls being made by that function to unwind immediately?
  
  I can see how this might work for explicit waits (Sleep, WaitForSingleObjectEx) since you already have handing for being interrupted by APCs there in the form of alertable waits, but what about in the general case of e.g. ReadFile? Does your explanation imply that there a way to cause arbitrary kernel functions to unwind instantly without corrupting internal kernel state, or do you just wait for all such calls to terminate naturally before doing the cleanup just before the kernel -> user transition as normal? But in the case of long running calls kernel mode functions I could see that being a problem..
  
  Thanks in advance!
  
  BSP
  

• 

  Thanks for this video. It helped me understand how windows manages threads that I program in my apps. Great video. Keep it up.

• 

  Sorry if this was not clear.
  
  Threads only ever "die" on the return to user mode. For the same reason, system threads cannot be terminated. Instead, they must voluntarily exit (direct call to terminate), or exit their main routine. Most kernel code will continue to run uninterrupted, however, the assumption is that unbounded kernel-mode waits, etc. should not be easily controllable by a user. User-mode waits, however, are instantly aborted in the kernel once the kernel-mode half of the terminate APC is delivered.
  
  You are absolutely right that long running kernel code, or code running with APCs disabled in kernel, will not take the kernel APC or will otherwise not terminate immediately. So TerminateThread really ensures that the target will no longer run in usermode, not that it will instantly unwind its kernel state and exit. I was only trying to stress that the mechanism is designed to ensure kernel state is unwound rather than exiting in place.

• 

  Hey, the link to the whitepaper does not work.
  

• 

  Alexis wrote:

  Hey, the link to the whitepaper does not work.
  

  
  
  Fixed. Thanks for pointing that out...
  C

• 

  Few questions:
  
  1)  About code injection: crackers and hackers now , cannot do code injection into running processes? Like dll injection will fail? Will this also affect global system hooks? like mouse hook and the likes?
  
  how is that actually good?
  
  
  
  2) What happens when the system is low on threads? when you do something like, QueueWorkItem, and use the system threads to do work in your application, and you "abuse this", in a server application, what would happen to the system at this stage when its under stress? Does it shutdown? or just queues the new work items until an existing system thread is free to process it? Can a new thread be created and added to the system thread pool/ Is this actually a good thing or a bad thing for a uniprocessor system?
  
  3) Is it actually good to use the system thread pool or to create a new unique thread for your specific application? 

• 

  1) Code injection is only limited for the protected processes, which are not meant to provide arbitrary extensibility by design. These processes can only load specially digitally signed code. The goal is to limit what can run inside them.
  
  2) There is no one-one mapping between work items and threads. Work queues and the threadpool try to manage the number of threads based on the workload / CPU availability. For example, the Vista threadpool tries to keep # CPU threads running, but will throttle threads back when it detects this number has been exceeded. Additional threads are created as needed in this range; the excess work items accumulate and are serviced by threads as they become available.
  
  3) It depends on your application. If it is a piece of code you just want to execute asynchronously, threadpool provides an efficient and simple means of accomplishing this. It does, however, introduce additional overhead. In other cases, you may need a dedicated thread for a task whose operation / life cycle you may need finer grained control over.

• 

  Wrong post...
  

• 

  arunki wrote:

  1) Code injection is only limited for the protected processes, which are not meant to provide arbitrary extensibility by design. These processes can only load specially digitally signed code. The goal is to limit what can run inside them.
  
  2) There is no one-one mapping between work items and threads. Work queues and the threadpool try to manage the number of threads based on the workload / CPU availability. For example, the Vista threadpool tries to keep # CPU threads running, but will throttle threads back when it detects this number has been exceeded. Additional threads are created as needed in this range; the excess work items accumulate and are serviced by threads as they become available.
  
  3) It depends on your application. If it is a piece of code you just want to execute asynchronously, threadpool provides an efficient and simple means of accomplishing this. It does, however, introduce additional overhead. In other cases, you may need a dedicated thread for a task whose operation / life cycle you may need finer grained control over.

  
  
  
  
  Thanks for the reply. I like the new protected process with in vista. But I wish if we can have examples as to how to create a protected process using Visual Studio 2005 in C#. Like an introduction as to how to create a protected application.
  
  Also, in the video , it was mentioned that the END PROCESS api will just kill of the process on the spot and this should be used only as a last measure, and if we know the state the process is in (most of us dont know that because we did not write the application that might go on a loop or hangs). But there are "Service" processes that simply refuse to be killed. You often get "Access denied" or something along those words. Can you explain that?

• 

  Great and detailed on Porcess/Thread. I have been using threads in user mode and it is nice to know more about the implementation of process/thread in O/S. I am not sure if I understand 100% about the subject(s) (I probably need to revisit the clip again). One thing I don't get it is system process (pid = 4) and system idle process. How they are related and who got created first?

   

   

  Thanks

• 

  This was great. I had been wondering how this worked for quite some time.

• 

  Thanks for the video !!
  
  Thanks and regards,
  Pranav
  

• 

  It is great to see an India sitting over there! can I download the video ( difficult to surf online) can you send download link to my mail id svmourougan@yahoo.com

• 

  process management in windows vista i need to make a written project on this...plzz help...

• 

  Hi Arun,

   

  Great video!!

   

  I would like some clarifications on Terminate and SuspendThread - specifically when thread is executing in kernel.

   

  You mentioned that terminate kicks the thread out of waits. Is that true only of UserMode waits or also of KernelMode waits? If it is true of KernelMode waits, does it bring it out both alertable and non-alterable or only alertable?

   

  What are the mechanics of suspend? Does it also involve a kernel apc which queues a user apc which executes only when thread unwinds from kernel? Or in case of suspend does kernel apc itself suspend the thread?

  Thanks,

  Praveen