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.

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.