{"id":91811,"date":"2015-08-14T07:00:00","date_gmt":"2015-08-14T21:00:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/oldnewthing\/20150814-00\/?p=91811\/"},"modified":"2019-03-13T12:18:32","modified_gmt":"2019-03-13T19:18:32","slug":"20150814-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20150814-00\/?p=91811","title":{"rendered":"Windows started picking up the really big pieces of TerminateThread garbage on the sidewalk, but it’s still garbage on the sidewalk"},"content":{"rendered":"

Ah, Terminate­Thread<\/code>. There are still people who think that there are valid scenarios for calling Terminate­Thread<\/code>. <\/p>\n

\n

Can you explain how Exit­Thread<\/code> works? <\/p>\n

We are interested because we have a class called Thread­Class<\/code>. We call the Start()<\/code> method , and then the Stop()<\/code> method, and then the Wait­Until­Stopped()<\/code> method, and then the process hangs with this call stack: <\/p>\n

\nntdll!ZwWaitForSingleObject\nntdll!RtlpWaitOnCriticalSection\nntdll!RtlEnterCriticalSection\nntdll!LdrShutdownThread\nntdll!RtlExitUserThread\nkernel32!BaseThreadInitThunk\nntdll!RtlUserThreadStart\n<\/pre>\n
Can you help us figure out what’s going on? <\/p>\n<\/blockquote>\n
From the stack trace, it is clear that the thread is shutting down, and the loader (Ldr<\/code>) is waiting on a critical section. The critical section the loader is most famous for needing is the so-called loader lock<\/i> which is used for various things, most notably to make sure that all DLL thread notification are serialized. <\/p>\n
I guessed that the call to Wait­Until­Stopped()<\/code> was happening inside Dll­Main<\/code>, which created a deadlock because the thread cannot exit until it delivers its Dll­Main<\/code> notifications, but it can’t do that until the calling thread exits Dll­Main<\/code>. <\/p>\n
The customer did some more debugging: <\/p>\n
\n
The debugger reports the critical section as <\/p>\n
\nCritSec ntdll!LdrpLoaderLock+0 at 77724300\nWaiterWoken        No\nLockCount          3\nRecursionCount     1\nOwningThread       a80\nEntryCount         0\nContentionCount    3\n*** Locked\n<\/pre>\n
The critical section claims that it is owned by thread 0xa80<\/code>, but there is no such active thread in the process. In the kernel debugger, a search for that thread says <\/p>\n
\nLooking for thread Cid = a80 ...\nTHREAD 8579e1c0  Cid 0b58.0a80  Teb: 00000000 Win32Thread: 00000000 TERMINATED\nNot impersonating\nDeviceMap                 862f8a98\nOwning Process            0       Image:         <Unknown>\nAttached Process          84386d90       Image:         Contoso.exe\nWait Start TickCount      12938474       Ticks: 114780 (0:00:29:50.579)\nContext Switch Count      8             \nUserTime                  00:00:00.000\nKernelTime                00:00:00.000\nWin32 Start Address 0x011167c0\nStack Init 0 Current bae35be0 Base bae36000 Limit bae33000 Call 0\nPriority 10 BasePriority 8 PriorityDecrement 2 IoPriority 2 PagePriority 5\n<\/pre>\n
Contoso.exe<\/code> is our process. <\/p>\n<\/blockquote>\n
Okay, we’re getting somewhere now. The thread 0xa80<\/code> terminated while it held the loader lock. When you run the program under a debugger, do you see any exceptions that might suggest that the thread terminated abnormally? <\/p>\n
\n
We found the cause of the problem. We use Terminate­Thread<\/code> in the other place. That causes the thread to continue to hold the loader lock after it has terminated. <\/p>\n<\/blockquote>\n
It’s not clear what the customer meant by “the other place”, but no matter. The cause of the problem was found: They were using Terminate­Thread<\/code>. <\/p>\n
At this point, Larry Osterman was inspired to write a poem. <\/p>\n
How many times does
it have to be said: Never
call TerminateThread. <\/p><\/blockquote>\n
In the ensuing discussion, somebody suggested, <\/p>\n
One case where it is okay to use Terminate­Thread<\/code> is if the thread was created suspended and has never been resumed. I believe it is perfectly legal to terminate it, at least in Windows Vista and later. <\/p><\/blockquote>\n
No, it is not “perfectly legal,” for certain values of “perfectly legal.” <\/p>\n
What happened is that Windows Vista added some code to try to limit the impact of a bad idea. Specifically, it added code to free the thread’s stack when the thread was terminated, so that each terminated thread didn’t leak a megabyte of memory. In the parlance of earlier discussion, I referred to this as stop throwing garbage on the sidewalk<\/a>. <\/p>\n
In this case, it’s like saying, “It’s okay to run this red light because the city added a delayed green to the cross traffic.” The city added a delayed green to the cross traffic because people were running the light and the city didn’t want people to die. That doesn’t mean that it’s okay to run the light now. <\/p>\n
Unfortunately, the guidance that says “Sometimes it’s okay to call Terminate­Thread<\/code>” has seeped into our own Best Practices documents. The Dynamic-Link Library Best Practices<\/a> under Best Practices for Synchronization<\/i> describes a synchronization model which actually involves calling Terminate­Thread<\/code>. <\/p>\n
Do not do this<\/i>. <\/p>\n
It’s particularly sad because the downloadable version of the document<\/a> references both Larry and me telling people to stop doing crazy things in Dll­Main<\/code>, and terminating threads is definitely a crazy thing. <\/p>\n
(The solution to the problem described in the whitepaper is not to use Terminate­Thread<\/code>. It’s to use the Free­Library­And­Exit­Thread<\/code> pattern<\/a>.) <\/p>\n
Now the history. <\/p>\n
Originally, there was no Terminate­Thread<\/code> function. The original designers felt strongly that no such function should exist because there was no safe way to terminate a thread, and there’s no point having a function that cannot be called safely. But people screamed that they needed the Terminate­Thread<\/code> function, even though it wasn’t safe, so the operating system designers caved and added the function because people demanded it. Of course, those people who insisted that they needed Terminate­Thread<\/code> now regret having been given it. <\/p>\n
It’s one of those “Be careful what you wish for” things. <\/p>\n","protected":false},"excerpt":{"rendered":"
So stop throwing garbage on the sidewalk.<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[2],"class_list":["post-91811","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-history"],"acf":[],"blog_post_summary":"
So stop throwing garbage on the sidewalk.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/91811","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/users\/1069"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/comments?post=91811"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/91811\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/111744"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=91811"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=91811"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=91811"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}