C++/VB - Deadly embrace between SetUnhandledExceptionFilter() and thread rundown(???) in Server 2003

Asked By j_314

05-Jan-10 12:34 AM

When our application starts up we call SetUnhandledExceptionFIlter()
and save off the address it returns as the current exception handler.
When we are exiting we pass this saved value back into
SetUnhandledExceptionFIlter() to re-establish the exception handler
that existed before we started. We also start a couple of threads.

Very occasionally we find that we do not shut down cleanly and if we
take a look with the debugger we find two thread in the process with
the following call stacks. It appears there is some kind of deadly
embrace in the use of critical sections between the code in
SetUnhandledExceptionFilter() and whatever code the other thread is
running (probably as part of thread cleanup but we are not sure).

This is Windows Server 2003 R2 SP2 (Enterprise Edition).

Does anyone know whether this is a known problem? Something which has
been fixed perhaps in Server 2008?

Thread #1:
0	>	3520	Main Thread	Main Thread	_unlock	Normal	0
0	 	3200	Worker Thread	Win32 Thread	7c82860c	Normal	0
ntdll.dll!_ZwWaitForSingleObject@12()  + 0xc bytes
ntdll.dll!_RtlpWaitOnCriticalSection@8()  - 0xe4 bytes
ntdll.dll!_RtlEnterCriticalSection@4()  + 0x22f51 bytes
ntdll.dll!_LdrLockLoaderLock@12()  + 0x6b bytes
kernel32.dll!_GetModuleFileNameW@12()  + 0x51 bytes
kernel32.dll!_FillUEFInfo@8()  + 0x4d bytes
digger.exe!__tmainCRTStartup()  Line 586 + 0x17 bytes	C
kernel32.dll!_BaseProcessStart@4()  + 0x23 bytes

Thread #2:
0	 	3520	Main Thread	Main Thread	_unlock	Normal	0
0	>	3200	Worker Thread	Win32 Thread	7c82860c	Normal	0
ntdll.dll!_KiFastSystemCallRet@0()
ntdll.dll!_ZwWaitForSingleObject@12()  + 0xc bytes
ntdll.dll!_RtlpWaitOnCriticalSection@8()  - 0xe4 bytes
ntdll.dll!_RtlEnterCriticalSection@4()  + 0x22f51 bytes
ntdll.dll!__LdrpInitialize@12()  + 0x56 bytes
ntdll.dll!_KiUserApcDispatcher@16()  + 0x25 bytes

05-Jan-10 03:14 AM

Hi j_3140!


IMHO there is no need to restore the original handler...

--
Greetings
Jochen

My blog about Win32 and .NET
http://blog.kalmbachnet.de/

07-Jan-10 10:39 AM

Thank you for the suggestion.

We included this code because we may be loaded as a DLL by some
other software package which may have a handler of its own and we are
trying to be a good citizen and leave the process state the same as
we
found it.

I suppose we could just remove this call to SetUnhandledExceptionFilter
()
but that still leaves a question as to whether there is some bug
here in the kernel which needs to be fixed. In general this kind of
deadly embrace is because someone has messed up the order of
acquisition of resources so the two threads are blocking each other.

07-Jan-10 02:23 AM

To me it looks like both of these threads are blocked on the loader
lock. Can you check which thread owns it? In windbg/cdb you can
use the following command to do this:

0:000> !cs ntdll!LdrpLoaderLock

--
Pavel Lebedinsky/Windows Fundamentals Test
This posting is provided "AS IS" with no warranties, and confers no rights.

08-Jan-10 09:16 PM

In my experience, several of the Windows DLLs do not shutdown cleanly
(specifically DNS APIs and others)  and a call to ExitProcess from the main
thread is necessary.  This is usually performed by the CRT when Main
returns, but may not be for some special applications.  IMHO, the shutdown
logic is less well tested and debugged in Windows than the other APIs.

07-Jan-10 07:44 AM

http-equiv="Content-Type">
cite="mid:2340b5b1-382a-4285-9a8a-91d0724eeb1b@f5g2000yqh.googlegroups.com"
type="cite">
and save off the address it returns as the current exception handler.
When we are exiting we pass this saved value back into <code>SetUnhandledExceptionFilter()</code>
to re-establish the exception handler that existed before we started.
We also start a couple of threads.<br>
href="http://blogs.msdn.com/oldnewthing/archive/2007/05/03/2383346.aspx">this</a>,
href="http://blogs.msdn.com/oldnewthing/archive/2009/02/06/9400367.aspx">this</a>,
and <a
href="http://blogs.msdn.com/oldnewthing/archive/2008/05/06/8461730.aspx">this</a>. 
Don't assume that you can cleanly use multiple threads after the main
thread (or, indeed, any thread) has commenced process exit.<br>

11-Jan-10 09:20 AM

http-equiv="Content-Type">
cleanly (specifically DNS APIs and others)  and a call to ExitProcess
from the main thread is necessary.  </p>

19-Jan-10 10:58 PM

http-equiv="Content-Type">
type="cite">
style="border-left: 2px solid rgb(0, 0, 0); padding-left: 5px; padding-right: 0px; margin-left: 5px; margin-right: 0px;">
type="cite">
cleanly (specifically DNS APIs and others)  and a call to <code>ExitProcess</code>
from the main thread is necessary.  </p>

21-Jan-10 12:42 PM

No worries.