Arun Kishan - Process Management in Windows Vista | Going Deep

Cyonix
Me

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

Good stuff

batterseapower

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

SecretSoftware
Code to live, but Live to code.

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

arunki

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.

Alexis

Hey, the link to the whitepaper does not work.

Charles
Welcome Change

Alexis wrote:
Hey, the link to the whitepaper does not work.

Fixed. Thanks for pointing that out...
C

SecretSoftware
Code to live, but Live to code.

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?

arunki

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.

LiQ

Wrong post...