Someone else can be more specific, but the caution about creating a worker
thread under Windows 2000, 98, & Me in any context other than the system
process still exists in the WDK 6000 docs.
On XP and later the OBJ_KERNEL_HANDLE bit can be used to keep even handles
created in a user process context from being accessed while in user mode. A
thread creates a handle to itself (ok, the OS creates the handle for the
thread) and allowing access to that handle from user mode does appear to
offer far too much of a security threat to be permissible. On XP and later
the OBJ_KERNEL_HANDLE can be used to create the thread where the process
context is -1 (current) and no user mode code can refer to that thread’s
handle.
Maybe those bits of info above are why the documentation reads as it does
and why Doron said to just schedule a work item to the system worker thread
queue where your own worker thread can be created for subsequent use. I
have found upon occasion to use a worker thread that runs in the context of
the user process, but it was only for testing and not release. I generally
avoid using the system worker threads and prefer to create my own as OSR
published in the NT Insider around 1998. NT4 had a major restriction on the
number available and if you use work items run by the system threads in the
storage stack especially you could deadlock the system. Not a good idea in
the file system stack either on NT4. Since I became proficient in creating
my own, I just prefer them and they remain dedicated to me for whenever I
need them.
–
David J. Craig
Engineer, Sr. Staff Software Systems
Broadcom Corporation
wrote in message news:xxxxx@ntdev…
> Peter,
>
>>Ah… this is often mis-understood. It’s a problem of naming.
>
>>The docs stating you must call PsCreateSystemThread in the system context
>>are
>> trying to save you from “doing the wrong thing” unintentionally. While
>> there’s
>> no prohibition against creating a system thread in process context, you
>> best be
>> sure that’s what you want… most people expect a “system thread” to
>> always
>> execute in the context of the system process, and to do this, the thread
>> must be
>> created in that context.
>
>> Let’s start with what a “system thred” is… it’s a thread that doesn’t
>> have any
>> user-mode context associated with it. Thus, it’s a kernel-mode only
>> thread. A
>> “system thread” as created by PsCreateSystemThread, must be associated
>> with some
>> process. It is NOT automatically associated with the system process.
>
>> If you call PsCreateSystemThread in the context of a specific process,
>> that
>> thread becomes part of the process in which the thread was created. This
>> carries with it all that “process context” implies – memory mapping in
>> the low
>> half of Kernel Virtual address space, for example.
>
>> Moral of the story: If you want a thread that always runs in the context
>> of the
>> system process, you need to call PsCreateSystemThread in the context of
>> the
>> system process.
>
>
> I am afraid the above is not entirely correct…
>
> Indeed, it is safer to create a kernel thread in context of the system
> process. However, context of a process that newly-created thread will
> belong to has nothing to do with a caller’s context. Instead, it is
> defined by ‘ProcessHandle’ parameter, which is optional - if you specify
> NULL, newly-created thread will run in context of a system process. The
> doc in question, indeed, tries to save you from “doing the wrong thing”
> unintentionally - it says that drivers should specify NULL for
> ‘ProcessHandle’ , and it says so in absolutely all versions of DDK, as
> well as in WDK.
>
> Therefore, taking into account the above, W2K DDK’s statement that the OP
> has mentioned either means that under W2K newly-created threadalways
> runs in a caller context, regardless of ‘ProcessHandle’ parameter, or is
> nothing more than just another bug in W2K DDK documentation that got
> subsequently fixed in WDK.
>
>
> I believe the latter is much more likely to be the case here…
>
> Anton Bassov
>
>
>
>
