Following up on this somewhat old thread just to correct some misunderstandings about the nature of the Windows APIs. On 25/01/2015 19:49, Michel SALES wrote: > Hi Avery, > >> In the code I sent over before, I was calling CloseHandle on the thread: >> HANDLE h1=CreateThread(0,0,thread1,0,0,&t1); if(h1==0) { return > 0; } CloseHandle(h1); > > Yes, but you were trying to close the handle of a thread which was still > running ! > I have not checked what happens in this case. Just FYI: On Windows (unlike the fork-like semantics of POSIX pthreads), the handle to a thread is just one of N references to the thread object, another of which is the actual fact of the thread still running. As long as at least one such reference exists, the kernel resources associated with the thread (an ETHREAD structure, the thread identifier etc.) remain in use. The act of waiting for and/or closing the handle has no direct relationship to thread exit. So closing an unwanted thread handle right after thread creation is a normal and correct resource saving coding technique. > I am not sure to fully understand what your are doing now, but with the > modified version I've sent to you, _CrtDumpMemoryLeaks() doesn't report any > problem on my Windows 7 64 bits machine. Note that _Crt functions only check internal state in the per-compiler C runtime, they cannot check for leaks of OS level objects, that requires OS tools, such as those available via Task manager (taskmgr.exe) and the OS level debuggers (WinDbg.exe, GFlags.exe etc.). Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded