Richard,
Thanks for the suggestion.

However, I am not creating any threads. Threads are being created by
the client (HTA, VB) so I am assuming these are being shutdown
correctly. Also since DLL_PROCESS_DETACH is called I can assume process
is exiting cleanly.

The next thing I am going to do is write a C++ test client. At least I
have control over what threads are being created. I will let you know
if this bears any results.

regards

------------------------------------------
Mahmudul Hoque
t: +44 1582 414800
m: +44 7961 103217
f: +44 8701 307328
e: mahmudhoque.org

-----Original Message-----
From: Distributed COM-Based Code [mailto:DCOMDISCUSS.MICROSOFT.COM] On
Behalf Of Rick Hobbs
Sent: 24 July 2001 15:37
To: DCOMDISCUSS.MICROSOFT.COM
Subject: Re: OT : DLL_THREAD_DETACH not being called

Hi mahmud,

One idea that springs to mind is that the DLL is being unloaded before
the threads exit - i.e. if DllCanUnloadNow returns true and the process
unloads the DLL, it won't see any DLL_THREAD_DETACH's for any subsequent
threads that exit as it won't be in memory.

I seem to recall that there was a problems with services doing something
like this - i.e. exiting while some DLL's were doing a thread detach,
but
i can't remember the exact details.

The only other thing that i can think of is that the process is exiting
before the threads have been cleanly shutdown. In this case, MSDEV may
still let you know that the thread has exited, but may not run all the
thread detach code as it could have already unloaded the DLL etc. etc.

Just some ideas.

Richard Hobbs.
Neoworks Limited

> -----Original Message-----
> From: Mahmudul Hoque [mailto:hoqueTOTALISE.CO.UK]
> Sent: 24 July 2001 15:17
> To: DCOMDISCUSS.MICROSOFT.COM
> Subject: OT : DLL_THREAD_DETACH not being called
>
>
> Hello,
>
> I have implemented an COM in-proc server using C++ and ATL.
> It uses TLS to
> hold pointers to newed object.
> The problem is DLL_THREAD_DETACH is not being called for all
> the threads.
> Below is a debug output of all the calls made to DLLMain. As
> you can see
> threads 652,653,654,655 and 656 never call DLL_THREAD_DETACH.
> In the debug
> window of MSDEV all threads are reported exiting with code 0 (0x0), so
> terminate thread is not the problem.
>
> The in-proc server is being used from an HTA script (the same
> behaviour is
> observed with VB client)
>
> Can suggested any reasons why this could be happening?
>
> DLL_PROCESS_ATTACH 645
> DLL_THREAD_ATTACH 646
>
> DLL_THREAD_ATTACH 647
> DLL_THREAD_DETACH 647
>
> DLL_THREAD_ATTACH 648
> DLL_THREAD_DETACH 648
>
> DLL_THREAD_ATTACH 649
> DLL_THREAD_DETACH 649
>
> DLL_THREAD_ATTACH 650
> DLL_THREAD_DETACH 650
>
> DLL_THREAD_ATTACH 652 - no thread detach called!
> DLL_THREAD_ATTACH 653 - no thread detach called!
> DLL_THREAD_ATTACH 654 - no thread detach called!
> DLL_THREAD_ATTACH 655 - no thread detach called!
> DLL_THREAD_ATTACH 656 - no thread detach called!
>
> DLL_THREAD_DETACH 657
>
> DLL_THREAD_DETACH 646
> DLL_THREAD_DETACH 656
> DLL_PROCESS_DETACH 645
>
>
> Many thanks
>
> -mahmud
>
> ----------------------------------------------------------------
> Users Guide http://discuss.microsoft.com/archives/mailfaq.asp
> contains important info. Save time, search the archives at
> http://discuss.microsoft.com/archives/index.html .
> To unsubscribe, mailto:DCOM-signoff-requestDISCUSS.MICROSOFT.COM
>

----------------------------------------------------------------
Users Guide http://discuss.microsoft.com/archives/mailfaq.asp
contains important info. Save time, search the archives at
http://discuss.microsoft.com/archives/index.html .
To unsubscribe, mailto:DCOM-signoff-requestDISCUSS.MICROSOFT.COM

----------------------------------------------------------------
Users Guide http://discuss.microsoft.com/archives/mailfaq.asp
contains important info. Save time, search the archives at
http://discuss.microsoft.com/archives/index.html .
To unsubscribe, mailto:DCOM-signoff-requestDISCUSS.MICROSOFT.COM

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]