Thread termination bugs

ps\kill.c:
In PsReapThreads, the kernel uses ObCreateHandle to create a handle to the
current process in the current process' handle table. Furthermore, it goes on
to bugcheck if this fails. NtCurrentProcess() could be used here.

Additionally, ReactOS appears to be trying to free the stack associated with a
thread - however, this is completely deviant to the NT design, whereby the
creator of the thread is responsible for both allocating and freeing the thread
stack.

If this bug is fixed, CSRSS will leak thread stack pages each time a Win32
client terminates. This should be addressed simultaneously.

There is a 32-byte field in the TEB set aside as the thread termination stack
that, in real NT, is used in as follows in kernel32!ExitThread:

• Save current esp on termination stack.
• Set esp to termination stack.
• Use NtQueryVirtualMemory to determine the allocation base + allocation size
  of the original esp value.
• Use NtFreeVirtualMemory to free the original esp value.

kernel32!CreateThread uses NtAllocateVirtualMemory to allocate the thread's
stack.

Because NtCreateThread does not allocate the thread's stack (the caller does),
NtTerminateThread (or anything eventually called as a result of it) should not
free the stack.

Note that this only applies to the user stack; the kernel stack is allocated
and released automatically by the kernel.

I have verified that Microsoft Windows NT does not release the user stack of a
thread on termination by writing a program that creates a thread using the
native thread creation routine, terminates it using the native thread
termination routine, and then accesses the dead thread's stack post-mortem from
a different thread.