Re: WaitForSingleObject On Thread Handle In DLL_PROCESS_DETACH

Skywing [MVP] wrote:
Note that a similar problem happens with thread creation, too. When a
thread is created, the first thing it does is call out to NTDLL, acquire the
LoaderLock, and make DllMain(DLL_THREAD_ATTACH) calls. As a result, you
can't block on a new thread in DllMain or you'll deadlock, just the same as
you can't block on waiting for a thread in the current process to exit
cleanly in DllMain.

Thanks for the thorough and clear explanation.

What is strange is that the hang happens only occasionally. The host
process is Explorer.EXE. The DLL is a shell namespace extension. I am
calling a two C++ member functions on a static global C++ object:

p.enregister() - DLL_PROCESS_ATTACH
p.deregister() - DLL_PROCESS_DETATCH

p.enregister() spawns a thread and goes about its business.

p.deregister() signals to that same thread to terminate, and waits for
it to terminate.

Because p is a global static object, the destructor of p will be
automatically invoked at program termination. The destructor of p, by
design, will call p.deregister() if the DLL is being unloaded
(absolutely necessary to call p.deregister() at some point before
unloading the DLL).

If I simple avoid doing a p.deregister() in DLL_PROCESS_DETACH, an
exception will be thrown, because, as it turns out, p.deregister()
depends on a global static mutex being in existence to work. That
mutex is not guaranteed to be remain in existence until all global
objects that need it have been destructed, per C++ translation unit
rules. You can rest assure that explicity controlling the order of
destruction of global objects by placing all global
constructible/destructible objects in one translation unit will ruin
the form of my code in ways I cannot describe.

So I figured the logical place to do enregister()/deregister() was in
DllMain.

But this still does not explain why hanging occurs only occasionally.
If it is true that the critical section is acquired before traversal of
the module list, then that would be true each time, so hanging should
occur every time. Just to be sure, I will run under the debugger to
make sure it works as I have it most times.

Any other ideas appreciated.

Regards,

-Le Chaud Lapin-

.

Relevant Pages

  • Re: Help! my toolbar cause IE deadlock
    ... All calls to DllMain of any DLL are synchronized by the system with one ... DllMain is run under a loader lock (that critical section I mentioned ... terminate, but before it can do so, the system makes it call ...
    (microsoft.public.inetsdk.programming.webbrowser_ctl)
  • Re: Allocate and De-allocate in Multi-DLL Program
    ... These common routines each need the ability to cause the program to display a meaningful error message and, in the case of command-line programs, terminate with a unique return code in the event that they detect an uncorrectable error. ... It seems likely that throwing and catching involves allocating and de-allocating an object and I've read here about the problem resulting from de-allocating an object in a module that may be using a different heap than the object that allocated it. ... Some thought and experimentation has persuaded me that, if an object has a virtual destructor and both constructor and destructor are inline, delete will call the destructor in the same module that constucted the object, regardless of where the delete is. ... I could link the programs and all of the DLLs with the DLL run-time libraries. ...
    (microsoft.public.vc.language)
  • Re: WaitForSingleObject On Thread Handle In DLL_PROCESS_DETACH
    ... The usual approach is to perform all non-trivial cleanup before ... Note that COM can release your DLL even ... The DLL is a shell namespace extension. ... Because p is a global static object, the destructor of p will be ...
    (microsoft.public.win32.programmer.kernel)
  • Re: convert C++ to C# or using managed C++ with VB.Net
    ... > to use the DLL in a larger VB.Net program. ... the C++ syntax for a destructor. ... Managed C++ produces .NET assemblies. ... the language used to create it. ...
    (microsoft.public.dotnet.general)
  • _CrtIsValidHeapPointer problem while exporting dll vc6.
    ... I am facing a problem while exporting a dll ... which uses the std::string, in to an exe. ... the destructor this error is occured. ... be asserting using the dll's heap there should not be any problem. ...
    (microsoft.public.vc.stl)
Quantcast