I just never found it comfortable to call PsTerminateSystemThread, call
it “old habits dying hard”. It just seemed more logical to let the
thread exit normally. Maybe it is just paranoia on my part…
–Mark Cariddi
OSR, Open Systems Resources, Inc…
I just never found it comfortable to call PsTerminateSystemThread, call
it “old habits dying hard”. It just seemed more logical to let the
thread exit normally. Maybe it is just paranoia on my part…
–Mark Cariddi
OSR, Open Systems Resources, Inc…
>
I just never found it comfortable to call PsTerminateSystemThread,
call it
“old habits dying hard”. It just seemed more logical to let the
thread exit
normally. Maybe it is just paranoia on my part…
PsTerminateSystemThread allows you to pass an ‘ExitStatus’ which could
be useful but I don’t actually know how to get at it… presumably there
is some magic you can weave using the handle or the thread object.
Other than that I don’t think there is a difference between using
PsTerminateSystemThread and just letting the function end.
James
The thread that is exiting calls PsTerminateSystemThread so there isn’t a concern about terminating the thread while it is in an indeterminite state (e.g. holding a lock or so on and so forth), assuming that you use PsTerminateSystemThread.
James is correct in that waiting for an event set by the system thread is sprinkling dangerous race conditions about in that you have no way to know whether the system thread has finished exiting before the driver unloads. This leads to a bug check should you lose the race (or worse if someone can spray an allocation where the threads thread routine used to be in memory).
That programming paragidm is contingent on the image that holds the thread routines code never, ever being unloaded for the life of the execution environment and is thus typically dangerous for any sort of unloadable driver.
As James said, the recommended approach to take is to wait on the thread handle, which guarantees that you’re safe from this race condition.
From: Mark Cariddi
Sent: Wednesday, August 26, 2009 05:31
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Ensuring all threads are terminated before unloading
I just never found it comfortable to call PsTerminateSystemThread, call it “old habits dying hard”. It just seemed more logical to let the thread exit normally. Maybe it is just paranoia on my part…
–Mark Cariddi
OSR, Open Systems Resources, Inc…
—
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
>
As James said, the recommended approach to take is to wait on the
thread
handle, which guarantees that you’re safe from this race condition.
I know what you meant, but it caused me a BSoD or two when I was first
learning - you have to wait on the thread object not the thread
handle. When you call PsCreateSystemThread you get a thread handle,
and then you get the thread object by calling ObReferenceObjectByHandle,
and you wait on that.
James
James:
Your post about handles and objects solved a problem that has bedeviled me for days. A huge thanks, and here’s a standing offer to buy you a cold adult beverage of your choice if I ever make it back to Australia, or if you ever make to New Mexico!