Hi.
Let’s assume that driver is performing PsCreateSystemThread() and creates system thread.
Is it possible to terminate this thread from this driver?
Thanks for joining discussion.
Yes, you can. The clean way is to return from the StartRoutne, you can
also use PsTerminateSystemThread to suicide.
Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
“xxxxx@gmail.com” wrote in message
news:xxxxx@ntdev:
> Hi.
>
> Let’s assume that driver is performing PsCreateSystemThread() and creates system thread.
> Is it possible to terminate this thread from this driver?
>
> Thanks for joining discussion.
Don thanks for joining.
Maybe my previous post wasn’t clear.
I understand that system thead can kill itself via returning from it’s routine or calling PsTerminateSystemThread, but my question is rather if driver can kill this thread.
Thanks so much for help.
Drivers don’t execute, threads do. There is not a clean documented way
of killing a thread from another thread in the kernel. Most people
design their code so that when the thrad they created is waiting for
work to do, it also has an event that it can wait on to terminate.
Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
“xxxxx@gmail.com” wrote in message
news:xxxxx@ntdev:
> Don thanks for joining.
>
> Maybe my previous post wasn’t clear.
> I understand that system thead can kill itself via returning from it’s routine or calling PsTerminateSystemThread, but my question is rather if driver can kill this thread.
>
> Thanks so much for help.
Don thanks again,
Ok I see, so what with undocumented ways?
Is there any structure in windows internals so that it keeps tracking of this threads, so that I could (even in illegal way) reach it?
Thank you.
No, there is not. What problem are you trying to solve?
d
debt from my phone
From: xxxxx@gmail.com
Sent: 11/5/2011 1:03 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] termination of system thread
Don thanks again,
Ok I see, so what with undocumented ways?
Is there any structure in windows internals so that it keeps tracking of this threads, so that I could (even in illegal way) reach it?
Thank you.
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
No. Wait on an event in the thread and when it is time for the thread to exit, set the event and write the thread routine in such a way so as that it exits the thread when the event is set.
- S (Msft)
From: xxxxx@lists.osr.com [xxxxx@lists.osr.com] on behalf of xxxxx@gmail.com [xxxxx@gmail.com]
Sent: Saturday, November 05, 2011 1:06 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] termination of system thread
Don thanks again,
Ok I see, so what with undocumented ways?
Is there any structure in windows internals so that it keeps tracking of this threads, so that I could (even in illegal way) reach it?
Thank you.
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
Why would you want to do this? Reaching into system structures is a
sure way to crash the system, which of course will terminate the thread.
THIS IS REALLY A BAD DESCIGN TO REQUIRE EXTERNAL THREAD TERMINATION.
Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
“xxxxx@gmail.com” wrote in message
news:xxxxx@ntdev:
> Don thanks again,
>
> Ok I see, so what with undocumented ways?
> Is there any structure in windows internals so that it keeps tracking of this threads, so that I could (even in illegal way) reach it?
>
> Thank you.
Don, Ken - Thank you for your answers. 
Yes, you can always terminate a thread. The key is that the thread has to
be designed to terminate itself, and you establish how this is done. It
can be as trivial as a simple boolean variable being changed, or as
complex as a “kill yourself” packet put in a queue you are using to
communicate with it. Since you have given not the slightest hint of what
this thread is doing or how it is doing it, it is impossible to suggest
which. of the numerous designs would be the best choice.
joe
Hi.
Let’s assume that driver is performing PsCreateSystemThread() and creates
system thread.
Is it possible to terminate this thread from this driver?Thanks for joining discussion.
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
I generally assert that the ONLY correct way to terminate a thread is
toreurn from its top-level. routine. It is truly amazing how many bugs
can be introduced to code that uses a please-terminate-me call. The
outcome is usually an unmaintainable mess. Many years of fixing other
people’s multithreaded apps has made this apparent.
joe
Yes, you can. The clean way is to return from the StartRoutne, you can
also use PsTerminateSystemThread to suicide.Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr“xxxxx@gmail.com” wrote in message
> news:xxxxx@ntdev:
>
>> Hi.
>>
>> Let’s assume that driver is performing PsCreateSystemThread() and
>> creates system thread.
>> Is it possible to terminate this thread from this driver?
>>
>> Thanks for joining discussion.
>
>
> —
> 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
>
Of course your driver can terminate a thread it creates. As I said
earlier, you have to establish a communication mechanism by which the
driver requests the thread terminate itself, preferably by forcing it to
return from its top-level routine.
joe
Don thanks for joining.
Maybe my previous post wasn’t clear.
I understand that system thead can kill itself via returning from it’s
routine or calling PsTerminateSystemThread, but my question is rather if
driver can kill this thread.Thanks so much for help.
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
That is one of many possible ways to ask a thread to terminate. It is
important to realize that when the two-waitable-object approach is used,
the order the appear in the array is critical. Sometimes you make the
cancel event be first, giving cancellation the priority; sometimes, you
put it last, meaning after all other work is done it should terminate.
For any given thread, it is important to consider the consequences of each
of these arrangements.
joe
Drivers don’t execute, threads do. There is not a clean documented way
of killing a thread from another thread in the kernel. Most people
design their code so that when the thrad they created is waiting for
work to do, it also has an event that it can wait on to terminate.Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr“xxxxx@gmail.com” wrote in message
> news:xxxxx@ntdev:
>
>> Don thanks for joining.
>>
>> Maybe my previous post wasn’t clear.
>> I understand that system thead can kill itself via returning from it’s
>> routine or calling PsTerminateSystemThread, but my question is rather if
>> driver can kill this thread.
>>
>> Thanks so much for help.
>
>
> —
> 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
>
Let’s just say that anything outside the thread that can terminate the
thread falls under the category of “Stupid design error”. If your thread
is so poorly designed that you have to kill it externally, by documented
(e.g., in an app, TerminateThread) or undocumented (suicidally dangerous)
means, your thread is improperly designed. Redesign it. Note that I have
been writing multithreaded code for decades, so if you try to tell me that
it cannot be done, I know you are wrong.
joe
Don thanks again,
Ok I see, so what with undocumented ways?
Is there any structure in windows internals so that it keeps tracking of
this threads, so that I could (even in illegal way) reach it?Thank you.
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
wrote in message news:xxxxx@ntdev…
> Let’s just say that anything outside the thread that can terminate the
> thread falls under the category of “Stupid design error”.
The Posix Threads API has notion of thread cancelation.
Is it is “stupid design error”?
–pa
>“The Posix Threads API has notion of thread cancelation. Is it is “stupid design error”?”
Thread cancellation only occurs on well defined cancel points. Those occur at certain function calls. If you just run a calculation, you have to test for cancel periodically.
In other words, it requires the target thread cooperation. How is that different from what Dr Joe is saying?
wrote in message news:xxxxx@ntdev…
>>“The Posix Threads API has notion of thread cancelation. Is it is “stupid
>>design error”?”
>
> Thread cancellation only occurs on well defined cancel points. Those occur
> at certain function calls. If you just run a calculation, you have to test
> for cancel periodically.
>
> In other words, it requires the target thread cooperation. How is that
> different from what Dr Joe is saying?
Let’s take this to nttalk. Thanks.
– pa
Terminating a thread arbitrarily is like catching an arbitrary unhanded exception. You have no idea the state of the thread and it’s data structures at the time of termination. Once you do the work to ensure the thread can always exit cleanly, you’re usually well beyond terminateThread
-p
On Nov 5, 2011, at 7:59 PM, “Pavel A.” wrote:
> wrote in message news:xxxxx@ntdev…
>> Let’s just say that anything outside the thread that can terminate the
>> thread falls under the category of “Stupid design error”.
>
> The Posix Threads API has notion of thread cancelation.
> Is it is “stupid design error”?
> --pa
>
> —
> 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
>
I depends on how it is implemented. If you can just reach out and kill a
thread, then using this capability would be a stupid design decision. The
existence of a feature does not prove the sensibility of its design, or
the sensibility of using the feature.
There is a TerminateThread API in Windows. The fact that it exists does
not mean that using it ever makes sense. I’ve had this same argument in
app space with people who want to use TerminateThread.
joe
wrote in message news:xxxxx@ntdev…
>> Let’s just say that anything outside the thread that can terminate the
>> thread falls under the category of “Stupid design error”.
>
> The Posix Threads API has notion of thread cancelation.
> Is it is “stupid design error”?
> --pa
>
>
> —
> 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
>
I agree completely. The usual question that no one can answer when I pose
it (for applications) is “How do you know the thread is not in the middle
of malloc?” If you kill a thread at this point, the user heap remains
permanently locked against all other threads, and eventually the app
grinds to a halt.
This is the same reason that we have “alertable wait state” for callbacks,
and no “signal” capability. These all require deducing the state of the
code and data at the point of occurrence, and it is worth pointing out
that Dave Cutler, the architect of VMS, had already made these mistakes in
VMS and was not about to repeat them.
While TerminateThread has uses in exceptional, extremely rare, very
special situations, and in fact is necessary in such situations, it is not
safe to use in real apps, and should never be written by application
programmers. The exceptions to this rule are so rare that you need large
negative exponents to express them.
Therefore, it is well-established that the idea of killing a thread from
outside the thread is a Really Bad Idea, and the counterexamples to any
proposal are so trivial to construct that the subject is not worth
debating.
joe
Terminating a thread arbitrarily is like catching an arbitrary unhanded
exception. You have no idea the state of the thread and it’s data
structures at the time of termination. Once you do the work to ensure the
thread can always exit cleanly, you’re usually well beyond terminateThread-p
On Nov 5, 2011, at 7:59 PM, “Pavel A.” wrote:
>
>> wrote in message news:xxxxx@ntdev…
>>> Let’s just say that anything outside the thread that can terminate the
>>> thread falls under the category of “Stupid design error”.
>>
>> The Posix Threads API has notion of thread cancelation.
>> Is it is “stupid design error”?
>> --pa
>>
>> —
>> 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
>>
>
> —
> 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
>