Why would CoUninitialize() hang?

[Tim Stotelmeyer]

I have a DLL which starts a thread the first time any of the DLL's
functions are accessed. This thread calls CoInitializeEx(NULL,
COINIT_MULTITHREADED) and then CoCreateInstance to get an interface
object.

When the DLL's DllMain is called during a FreeLibrary the
DLL_PROCESS_DETACH code sets an event in the thread and then waits for
that thread to exit.

The thread releases the interface object and then calls
CoUninitialize(). Which hangs after calling the COM module's
DllCanUnloadNow() function. DllCanUnloadNow() does return TRUE.

As a test I added code so that the thread shutdown is initiated outside
of DLL_PROCESS_DETACH to see what would happen. The CoUninitialize()
does not hang.

Why would CoUninitialize() in one thread hang if the DLL is also
processing DLL_PROCESS_DETACH?

Tim

[Per Larsen]

Tim,

Must be a threading issue. Calls to DllMain are serialized. Apparently, your
call to CoUninitialize causes COM to attempt to shut down a notification
thread or something, which in turn attempts to notify your DLL. You may be
able to get around it by calling DisableThreadLibraryCalls in response to
DLL_PROCESS_ATTACH. If that doesn't help you need to rethink your threading
settings.

- Per

"Tim Stotelmeyer" <ti...@attachmate.com> wrote in message
news:3B096069...@attachmate.com...

[Jason Hoy]

I don't suppose you are trying this in Windows Me ? I have a similar
problem where only in Windows Me my multi-threaded application crashes when
I call CoUninitialize. If your problem happens that same across operating
systems then sorry I wasted your time by reading this :)

Jason

"Tim Stotelmeyer" <ti...@attachmate.com> wrote in message
news:3B096069...@attachmate.com...

[Tim Stotelmeyer]

Per,

On your tip I tried DisableThreadLibraryCall. Unfortunately it did not help.
It was worth a try.

What's strange is that another DLL which uses a similar threading scheme and
uses the same COM interface object has no problem.

Tim

[Tim Stotelmeyer]

Jason,

So far I've only tested my problem with Windows 2000.

I have seen GPFs from the last CoUninitialize() when one of my other threads
forgot to call CoUninitialize() before it exited.

Tim

[Michael Jones]

Most properly you still have an unreleased object / interface somewhere.
Also it is a good idea to only call CoInitialize(..) in threads that you
actually want to be used as MTA "hubs". Have you got any threads wait in
WaitObject functions?

Michael

"Tim Stotelmeyer" <ti...@attachmate.com> wrote in message

news:3B09917A...@attachmate.com...

[Tim Stotelmeyer]

I've checked for unreleased interfaces and according to the global and
individual interface ref counts I'm releasing all of them. So that is not where
the hang is coming from. The individual ref counts were usefully to tracking
down which thread was not calling CoUninitialize.

I can duplicate the hang by starting only one thread. The CoUninitialize() is
the third to the last line in the thread's function so the thread is not in a
wait state by then. The second to the last line is a flag that I set that says
the thread is no longer running. The code in DLL_PROCESS_DETACH polls this flag
every 250 milliseconds. I supposed I could poll on GetExitCodeThread() instead
of using the flag.

[Indy]

To detect a terminated thread you should use WaitFor...Object(...) using the
thread handle. The Thread is "signaled" once ended. Now - other question -
have you got any message pump in that thread?

Michael

"Tim Stotelmeyer" <ti...@attachmate.com> wrote in message

news:3B0A7B69...@attachmate.com...

[Tim Stotelmeyer]

After installing the Checked and Debug version of Win2000 and stepping through
CoUninitialize() I tracked the problem down to the FreeLibrary call that
CoUninitialize eventually calls on the COM modules that were loaded.
FreeLibrary was waiting on a Critical Section which was blocked for some reason.

I did finally figure out why one of my DLLs was not hanging and the other one
was. The non-hanging DLL called CoInitializeEx in DLL_PROCESS_ATTACH and
CoUninitialize in DLL_PROCESS_DETACH. Where as the hanging DLL did not make
these calls. Once I added them in my hanging DLL stopped hanging.

It took me a week to figure this out. Ugh.

Tim