kernel system threads

NTDEV
1

when a system thread is created with

NTSTATUS status = PsCreateSystemThread(

&h,

(ACCESS_MASK) 0L,

NULL,

NULL,

NULL,

MYThreadHandler,

NULL

);

who owns this thread? is it associated with the driver that invoked this
call? or is it a kernel thread and is independent?

2

Owned by “system” process.

On Thu, Nov 26, 2009 at 10:03 AM, Bedanto wrote:

> when a system thread is created with
>
>
> NTSTATUS status = PsCreateSystemThread(
>
> &h,
>
> (ACCESS_MASK) 0L,
>
> NULL,
>
> NULL,
>
> NULL,
>
> MYThreadHandler,
>
> NULL
>
> );
>
>
>
> who owns this thread? is it associated with the driver that invoked this
> call? or is it a kernel thread and is independent?
> — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
> other seminars visit: http://www.osr.com/seminars To unsubscribe, visit
> the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer

3

> Owned by “system” process.

Actually, I have always been intrigued by the following explanation on MSDN

[begin quote]

ProcessHandle
Specifies an open handle for the process in whose address space the thread is to be run. The caller’s thread must have PROCESS_CREATE_THREAD access to this process. If this parameter is not supplied, the thread will be created in the initial system process. This value should be NULL for a driver-created thread. Use the NtCurrentProcess macro, defined in Ntddk.h, to specify the current process.

[end quote]

The term “owned” somehow implies that thread must terminate if the owner process exits. A thread that runs in the kernel mode cannot get terminated externally for whatever reason, so that thread external termination must be handled as a UM APC that gets processed upon the return to the UM. However, a thread created by PsCreateSystemThread() does not have its UM representation, and, hence, cannot get
terminated externally.

Therefore, my question is “What happens to the target thread if driver supplies non-NULL ProcessHandle parameter and the target process terminates before the thread does???” The only possible explanation that gets into my head that

1.The whole thing must be somehow related to possibility of loading process-specific kernel modules with ZwSetSystemInformation()

  1. By supplying non-NULL ProcessHandle parameter you reference the target address space so that it remains valid as long as refcount is non-zero even if apps’s main thread terminates

Could someone “in the know” shed some light on it, please…

Anton Bassov

4

>is it associated with the driver that invoked this call?

No.

or is it a kernel thread and is independent?

Yes.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com