Hang problem... Help Please!!

  • Thread starter Madhu Gopinathan
  • Start date
M

Madhu Gopinathan

Hi All,
I am faced with a horrible hang problem. I have a COM exe server that executes some tasks. The task execution manager is a thread that manages the pool of threads, which is 4 per processor. Each task is processed in a separate thread. Each of the executer threads is an STA thread, and it goes ahead and executes the task.
No problems are encountered when tasks are executed one at a time, but when multiple tasks are executed simultaneously, I am faced with a hang problem. The task executer thread on its way to executing calls on some VB components which are all apartment threaded.
Say, I give 10 tasks simultaneously for execution. Around four on an average execute successfully, and then the worker threads hang. I checked the call stack of the worker threads and I saw that one of the threads seem to hanging on a call to CoCreateInstance(). This CoCreateInstance call is to a VB component with further calls a LoadLibrary , sometimes for NetApi32.dll, sometimes for Kernel32.dll.

The call stack is shown below.

00 00000188 00000000 00000000 ntdll!ZwWaitForSingleObject+0xb
01 77fcf301 77f86d97 77fcf348 ntdll!RtlpWaitForCriticalSection+0x9e
02 77fcf348 062a2bec 00000000 ntdll!RtlEnterCriticalSection+0x46
03 03ebc718 094dee94 094dee9c ntdll!LdrpLoadDll+0x64
04 03ebc718 094dee94 094dee9c ntdll!LdrLoadDll+0x17
05 7ffabc00 00000000 00000000 KERNEL32!LoadLibraryExW+0x21b
06 21002f24 00000000 00000000 KERNEL32!LoadLibraryExA+0x1d
07 21002f24 00000001 21001da8 KERNEL32!LoadLibraryA+0xa0 <----- This LoadLibrary is for Kernel32, sometimes I get a hang for NetApi32.dll
08 21003070 00000001 094def3c MSVBVM60!GetPvDllFunction+0x34
09 21001da8 00000000 21003070 MSVBVM60!CreateProjExecContext_617+0x6d
0a 6aaaca1f 062a26f0 2100244c MSVBVM60!epiExeRoot::VisitExeRes+0x27
0b 21000000 21010080 00000000 MSVBVM60!CreateProjExecContext_223+0xe8
0c 21000000 21001da8 21001b70 MSVBVM60!EbLoadRunTime_63+0x9e
0d 21001b70 21000000 094df274 MSVBVM60!ProjOpenThread+0x77
0e 21001b70 21000000 6a9ff9b0 MSVBVM60!CVBThreadAction::SetProjectData+0x2e
0f 21000000 00000000 6a9ff9b0 MSVBVM60!CVBThreadAction::Start+0xd4
10 21001b70 21000000 0014bf30 MSVBVM60!CThreadPool::InitDllAccess+0x29
11 21010674 21010670 21001b70 MSVBVM60!VBDllGetClassObject+0x61
12 0014c340 77a55e48 094df3fc ole32!CClassCache::CDllPathEntry::DllGetClassObject+0x35
13 00000001 77a55e48 094df3fc ole32!CClassCache::CDllFnPtrMoniker::BindToObject+0x166
14 094df33c 094df3f0 1100580d ole32!CClassCache::SearchForLoadedClass+0x71
15 1100580c 00000000 00000005 ole32!ICoCreateInstanceEx+0xc9 <----- This CoCreateInstance is for a VB component
16 1100580c 00000000 00000005 ole32!CoCreateInstanceEx+0x2b
17 1100582c 061977bc 094df4b4 MSVBVM60!RcmConstructObjectInstance_54+0x112
18 1100582c 061977bc 00000001 MSVBVM60!__vbaNew2+0x20

The call stacks for the other 3 worker threads is as follows
0602fa8c 77f83955 ntdll!ZwWaitForSingleObject+0xb
0602fb00 77f838c6 ntdll!RtlpWaitForCriticalSection+0x9e
0602fb08 6a9e7412 ntdll!RtlEnterCriticalSection+0x46
0602fd7c 6a9e6e06 MSVBVM60!TipUnloadProject+0x20
0602fd90 6a9e6b49 MSVBVM60!ProjFDeleteThread+0x6e
0602fdac 6aa5770c MSVBVM60!CVBThreadAction::CleanupProjData+0x6c
0602fdbc 6aa0ee69 MSVBVM60!CThreadPool::CleanupAtDllDetach+0x14
0602fdd4 77f82fc9 MSVBVM60!UserDllMain_26+0x39
0602fdfc 77f84697 ntdll!LdrpCallInitRoutine+0x14
0602fe50 77e8762c ntdll!LdrShutdownThread+0xa3
0602feb8 004e88f6 KERNEL32!ExitThread+0x53
0602ff18 005618a6 WFExec!WFTaskExecuterThread::ThreadProc+0xbe [W:\bvAdminForWindows\Rules\Components\Workflow\WFCore\WFTaskExecuterThread.cpp @ 63]
0602ff80 7800a3c0 WFExec!Thread::ThreadProc+0x47 [W:\bvAdminShared\Reusable\Components\REReusableLib\Thread.cpp @ 106]
0602ffb4 77e8758a MSVCRT!_beginthreadex+0xca
0602ffec 00000000 KERNEL32!BaseThreadStart+0x52


The hang does not occur if I make the threading model of the VB components, single threaded instead of apartment thread. However, I need them to be apartment threaded due to impersonation reasons.

Can someone please help me here?

Regards,
Madhu
 
I

Ivan Brugiolo [MSFT]

This is a typical LoaderLock deadlock.
With the help of the system debuggers (ntsd/cdb/windbg)
you can use the `!cs' command to see who is owning the loader lock,
and from that point you should be able to figure out how to move forward
and/or break the deadlock.

Typically this happens because a component is waiting for a thread in
DllMain,
or it's performing a blocking RPC call from DllMain.

--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm


Hi All,
I am faced with a horrible hang problem. I have a COM exe server that
executes some tasks. The task execution manager is a thread that manages the
pool of threads, which is 4 per processor. Each task is processed in a
separate thread. Each of the executer threads is an STA thread, and it goes
ahead and executes the task.
No problems are encountered when tasks are executed one at a time, but
when multiple tasks are executed simultaneously, I am faced with a hang
problem. The task executer thread on its way to executing calls on some VB
components which are all apartment threaded.
Say, I give 10 tasks simultaneously for execution. Around four on an
average execute successfully, and then the worker threads hang. I checked
the call stack of the worker threads and I saw that one of the threads seem
to hanging on a call to CoCreateInstance(). This CoCreateInstance call is to
a VB component with further calls a LoadLibrary , sometimes for
NetApi32.dll, sometimes for Kernel32.dll.

The call stack is shown below.

00 00000188 00000000 00000000
ntdll!ZwWaitForSingleObject+0xb
01 77fcf301 77f86d97 77fcf348
ntdll!RtlpWaitForCriticalSection+0x9e
02 77fcf348 062a2bec 00000000
ntdll!RtlEnterCriticalSection+0x46
03 03ebc718 094dee94 094dee9c ntdll!LdrpLoadDll+0x64
04 03ebc718 094dee94 094dee9c ntdll!LdrLoadDll+0x17
05 7ffabc00 00000000 00000000 KERNEL32!LoadLibraryExW+0x21b
06 21002f24 00000000 00000000 KERNEL32!LoadLibraryExA+0x1d
07 21002f24 00000001 21001da8 KERNEL32!LoadLibraryA+0xa0
<----- This LoadLibrary is for Kernel32, sometimes I get a hang for
NetApi32.dll
08 21003070 00000001 094def3c MSVBVM60!GetPvDllFunction+0x34
09 21001da8 00000000 21003070
MSVBVM60!CreateProjExecContext_617+0x6d
0a 6aaaca1f 062a26f0 2100244c
MSVBVM60!epiExeRoot::VisitExeRes+0x27
0b 21000000 21010080 00000000
MSVBVM60!CreateProjExecContext_223+0xe8
0c 21000000 21001da8 21001b70 MSVBVM60!EbLoadRunTime_63+0x9e
0d 21001b70 21000000 094df274 MSVBVM60!ProjOpenThread+0x77
0e 21001b70 21000000 6a9ff9b0
MSVBVM60!CVBThreadAction::SetProjectData+0x2e
0f 21000000 00000000 6a9ff9b0
MSVBVM60!CVBThreadAction::Start+0xd4
10 21001b70 21000000 0014bf30
MSVBVM60!CThreadPool::InitDllAccess+0x29
11 21010674 21010670 21001b70
MSVBVM60!VBDllGetClassObject+0x61
12 0014c340 77a55e48 094df3fc
ole32!CClassCache::CDllPathEntry::DllGetClassObject+0x35
13 00000001 77a55e48 094df3fc
ole32!CClassCache::CDllFnPtrMoniker::BindToObject+0x166
14 094df33c 094df3f0 1100580d
ole32!CClassCache::SearchForLoadedClass+0x71
15 1100580c 00000000 00000005 ole32!ICoCreateInstanceEx+0xc9
<----- This CoCreateInstance is for a VB component
16 1100580c 00000000 00000005 ole32!CoCreateInstanceEx+0x2b
17 1100582c 061977bc 094df4b4
MSVBVM60!RcmConstructObjectInstance_54+0x112
18 1100582c 061977bc 00000001 MSVBVM60!__vbaNew2+0x20

The call stacks for the other 3 worker threads is as follows
0602fa8c 77f83955 ntdll!ZwWaitForSingleObject+0xb
0602fb00 77f838c6 ntdll!RtlpWaitForCriticalSection+0x9e
0602fb08 6a9e7412 ntdll!RtlEnterCriticalSection+0x46
0602fd7c 6a9e6e06 MSVBVM60!TipUnloadProject+0x20
0602fd90 6a9e6b49 MSVBVM60!ProjFDeleteThread+0x6e
0602fdac 6aa5770c
MSVBVM60!CVBThreadAction::CleanupProjData+0x6c
0602fdbc 6aa0ee69
MSVBVM60!CThreadPool::CleanupAtDllDetach+0x14
0602fdd4 77f82fc9 MSVBVM60!UserDllMain_26+0x39
0602fdfc 77f84697 ntdll!LdrpCallInitRoutine+0x14
0602fe50 77e8762c ntdll!LdrShutdownThread+0xa3
0602feb8 004e88f6 KERNEL32!ExitThread+0x53
0602ff18 005618a6
WFExec!WFTaskExecuterThread::ThreadProc+0xbe
[W:\bvAdminForWindows\Rules\Components\Workflow\WFCore\WFTaskExecuterThread.
cpp @ 63]
0602ff80 7800a3c0 WFExec!Thread::ThreadProc+0x47
[W:\bvAdminShared\Reusable\Components\REReusableLib\Thread.cpp @ 106]
0602ffb4 77e8758a MSVCRT!_beginthreadex+0xca
0602ffec 00000000 KERNEL32!BaseThreadStart+0x52


The hang does not occur if I make the threading model of the VB
components, single threaded instead of apartment thread. However, I need
them to be apartment threaded due to impersonation reasons.

Can someone please help me here?

Regards,
Madhu
 
M

Madhu Gopinathan

Hi Ivan,
Thanks for your quick response.
I did not come across any !cs command in windbg. Are you talking about
the !critlist command exported from the sieextpub.dll? If so, I do get a
deadlock situation sometimes, which tells me which thread is owning the
critical section that the others threads are blocking on. The two call
stacks I have given are those of the deadlocked threads.

However I cannot decipher any information from them because they seem to
be deadlocking in the system DLLs. One on the call to ExitThread, while the
other in LoadLibrary(for Kernel32).

Can you help me to unmangle the call stack? Any help will be greatly
appreciated.

Thanks again,
Madhu.



Ivan Brugiolo said:
This is a typical LoaderLock deadlock.
With the help of the system debuggers (ntsd/cdb/windbg)
you can use the `!cs' command to see who is owning the loader lock,
and from that point you should be able to figure out how to move forward
and/or break the deadlock.

Typically this happens because a component is waiting for a thread in
DllMain,
or it's performing a blocking RPC call from DllMain.

--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm


Hi All,
I am faced with a horrible hang problem. I have a COM exe server that
executes some tasks. The task execution manager is a thread that manages the
pool of threads, which is 4 per processor. Each task is processed in a
separate thread. Each of the executer threads is an STA thread, and it goes
ahead and executes the task.
No problems are encountered when tasks are executed one at a time, but
when multiple tasks are executed simultaneously, I am faced with a hang
problem. The task executer thread on its way to executing calls on some VB
components which are all apartment threaded.
Say, I give 10 tasks simultaneously for execution. Around four on an
average execute successfully, and then the worker threads hang. I checked
the call stack of the worker threads and I saw that one of the threads seem
to hanging on a call to CoCreateInstance(). This CoCreateInstance call is to
a VB component with further calls a LoadLibrary , sometimes for
NetApi32.dll, sometimes for Kernel32.dll.

The call stack is shown below.

00 00000188 00000000 00000000
ntdll!ZwWaitForSingleObject+0xb
01 77fcf301 77f86d97 77fcf348
ntdll!RtlpWaitForCriticalSection+0x9e
02 77fcf348 062a2bec 00000000
ntdll!RtlEnterCriticalSection+0x46
03 03ebc718 094dee94 094dee9c ntdll!LdrpLoadDll+0x64
04 03ebc718 094dee94 094dee9c ntdll!LdrLoadDll+0x17
05 7ffabc00 00000000 00000000 KERNEL32!LoadLibraryExW+0x21b
06 21002f24 00000000 00000000 KERNEL32!LoadLibraryExA+0x1d
07 21002f24 00000001 21001da8 KERNEL32!LoadLibraryA+0xa0
<----- This LoadLibrary is for Kernel32, sometimes I get a hang for
NetApi32.dll
08 21003070 00000001 094def3c MSVBVM60!GetPvDllFunction+0x34
09 21001da8 00000000 21003070
MSVBVM60!CreateProjExecContext_617+0x6d
0a 6aaaca1f 062a26f0 2100244c
MSVBVM60!epiExeRoot::VisitExeRes+0x27
0b 21000000 21010080 00000000
MSVBVM60!CreateProjExecContext_223+0xe8
0c 21000000 21001da8 21001b70 MSVBVM60!EbLoadRunTime_63+0x9e
0d 21001b70 21000000 094df274 MSVBVM60!ProjOpenThread+0x77
0e 21001b70 21000000 6a9ff9b0
MSVBVM60!CVBThreadAction::SetProjectData+0x2e
0f 21000000 00000000 6a9ff9b0
MSVBVM60!CVBThreadAction::Start+0xd4
10 21001b70 21000000 0014bf30
MSVBVM60!CThreadPool::InitDllAccess+0x29
11 21010674 21010670 21001b70
MSVBVM60!VBDllGetClassObject+0x61
12 0014c340 77a55e48 094df3fc
ole32!CClassCache::CDllPathEntry::DllGetClassObject+0x35
13 00000001 77a55e48 094df3fc
ole32!CClassCache::CDllFnPtrMoniker::BindToObject+0x166
14 094df33c 094df3f0 1100580d
ole32!CClassCache::SearchForLoadedClass+0x71
15 1100580c 00000000 00000005 ole32!ICoCreateInstanceEx+0xc9
<----- This CoCreateInstance is for a VB component
16 1100580c 00000000 00000005 ole32!CoCreateInstanceEx+0x2b
17 1100582c 061977bc 094df4b4
MSVBVM60!RcmConstructObjectInstance_54+0x112
18 1100582c 061977bc 00000001 MSVBVM60!__vbaNew2+0x20

The call stacks for the other 3 worker threads is as follows
0602fa8c 77f83955 ntdll!ZwWaitForSingleObject+0xb
0602fb00 77f838c6 ntdll!RtlpWaitForCriticalSection+0x9e
0602fb08 6a9e7412 ntdll!RtlEnterCriticalSection+0x46
0602fd7c 6a9e6e06 MSVBVM60!TipUnloadProject+0x20
0602fd90 6a9e6b49 MSVBVM60!ProjFDeleteThread+0x6e
0602fdac 6aa5770c
MSVBVM60!CVBThreadAction::CleanupProjData+0x6c
0602fdbc 6aa0ee69
MSVBVM60!CThreadPool::CleanupAtDllDetach+0x14
0602fdd4 77f82fc9 MSVBVM60!UserDllMain_26+0x39
0602fdfc 77f84697 ntdll!LdrpCallInitRoutine+0x14
0602fe50 77e8762c ntdll!LdrShutdownThread+0xa3
0602feb8 004e88f6 KERNEL32!ExitThread+0x53
0602ff18 005618a6
WFExec!WFTaskExecuterThread::ThreadProc+0xbe
[W:\bvAdminForWindows\Rules\Components\Workflow\WFCore\WFTaskExecuterThread.
cpp @ 63]
0602ff80 7800a3c0 WFExec!Thread::ThreadProc+0x47
[W:\bvAdminShared\Reusable\Components\REReusableLib\Thread.cpp @ 106]
0602ffb4 77e8758a MSVCRT!_beginthreadex+0xca
0602ffec 00000000 KERNEL32!BaseThreadStart+0x52


The hang does not occur if I make the threading model of the VB
components, single threaded instead of apartment thread. However, I need
them to be apartment threaded due to impersonation reasons.

Can someone please help me here?

Regards,
Madhu
Click to expand...
 
I

Ivan Brugiolo [MSFT]

Both the `!cs' and the `!locks' command are availalble.

Upon closer inspection, the VB runtime is most likely at fault,
since it's waiting for a critical section in the DllMain(THREAD_DETACH) code
path.
The loader lock is held while performing thread shutdown anyway, and then
the runtime is holding one more critical section.
The thread waiting on the LoaderLock inside LoadLibrary has an uncomplete
stack,
but most likely somewhere down the stack there is a code path
that holds the same critical section that is waited in the THREAD_DETACH
code path.

if you could report the output of the `~*kb 100' command in cdb/ntsd/windbg,
maybe there are more hints to support this thesis.

I'm not at all a VB expert, but maybe you can avoid this by preventing the
LoadLibrary call
somewhere in the "Project Startup" code-path.
Maybe there are certain restriction in causing the VB runtime to calll
LoadLibrary/GetProcaddress
in certain places of the VB code, the same way there are restrictions
about Loader-Lock sensitive options while holding other locks in the
traditional Win32.

--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm


Madhu Gopinathan said:
Hi Ivan,
Thanks for your quick response.
I did not come across any !cs command in windbg. Are you talking about
the !critlist command exported from the sieextpub.dll? If so, I do get a
deadlock situation sometimes, which tells me which thread is owning the
critical section that the others threads are blocking on. The two call
stacks I have given are those of the deadlocked threads.

However I cannot decipher any information from them because they seem to
be deadlocking in the system DLLs. One on the call to ExitThread, while the
other in LoadLibrary(for Kernel32).

Can you help me to unmangle the call stack? Any help will be greatly
appreciated.

Thanks again,
Madhu.



Ivan Brugiolo said:
This is a typical LoaderLock deadlock.
With the help of the system debuggers (ntsd/cdb/windbg)
you can use the `!cs' command to see who is owning the loader lock,
and from that point you should be able to figure out how to move forward
and/or break the deadlock.

Typically this happens because a component is waiting for a thread in
DllMain,
or it's performing a blocking RPC call from DllMain.

--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm


Hi All,
I am faced with a horrible hang problem. I have a COM exe server that
executes some tasks. The task execution manager is a thread that manages the
pool of threads, which is 4 per processor. Each task is processed in a
separate thread. Each of the executer threads is an STA thread, and it goes
ahead and executes the task.
No problems are encountered when tasks are executed one at a time, but
when multiple tasks are executed simultaneously, I am faced with a hang
problem. The task executer thread on its way to executing calls on some VB
components which are all apartment threaded.
Say, I give 10 tasks simultaneously for execution. Around four on an
average execute successfully, and then the worker threads hang. I checked
the call stack of the worker threads and I saw that one of the threads seem
to hanging on a call to CoCreateInstance(). This CoCreateInstance call
Click to expand...
is
to
a VB component with further calls a LoadLibrary , sometimes for
NetApi32.dll, sometimes for Kernel32.dll.

The call stack is shown below.

00 00000188 00000000 00000000
ntdll!ZwWaitForSingleObject+0xb
01 77fcf301 77f86d97 77fcf348
ntdll!RtlpWaitForCriticalSection+0x9e
02 77fcf348 062a2bec 00000000
ntdll!RtlEnterCriticalSection+0x46
03 03ebc718 094dee94 094dee9c ntdll!LdrpLoadDll+0x64
04 03ebc718 094dee94 094dee9c ntdll!LdrLoadDll+0x17
05 7ffabc00 00000000 00000000 KERNEL32!LoadLibraryExW+0x21b
06 21002f24 00000000 00000000 KERNEL32!LoadLibraryExA+0x1d
07 21002f24 00000001 21001da8 KERNEL32!LoadLibraryA+0xa0
<----- This LoadLibrary is for Kernel32, sometimes I get a hang for
NetApi32.dll
08 21003070 00000001 094def3c MSVBVM60!GetPvDllFunction+0x34
09 21001da8 00000000 21003070
MSVBVM60!CreateProjExecContext_617+0x6d
0a 6aaaca1f 062a26f0 2100244c
MSVBVM60!epiExeRoot::VisitExeRes+0x27
0b 21000000 21010080 00000000
MSVBVM60!CreateProjExecContext_223+0xe8
0c 21000000 21001da8 21001b70 MSVBVM60!EbLoadRunTime_63+0x9e
0d 21001b70 21000000 094df274 MSVBVM60!ProjOpenThread+0x77
0e 21001b70 21000000 6a9ff9b0
MSVBVM60!CVBThreadAction::SetProjectData+0x2e
0f 21000000 00000000 6a9ff9b0
MSVBVM60!CVBThreadAction::Start+0xd4
10 21001b70 21000000 0014bf30
MSVBVM60!CThreadPool::InitDllAccess+0x29
11 21010674 21010670 21001b70
MSVBVM60!VBDllGetClassObject+0x61
12 0014c340 77a55e48 094df3fc
ole32!CClassCache::CDllPathEntry::DllGetClassObject+0x35
13 00000001 77a55e48 094df3fc
ole32!CClassCache::CDllFnPtrMoniker::BindToObject+0x166
14 094df33c 094df3f0 1100580d
ole32!CClassCache::SearchForLoadedClass+0x71
15 1100580c 00000000 00000005 ole32!ICoCreateInstanceEx+0xc9
<----- This CoCreateInstance is for a VB component
16 1100580c 00000000 00000005 ole32!CoCreateInstanceEx+0x2b
17 1100582c 061977bc 094df4b4
MSVBVM60!RcmConstructObjectInstance_54+0x112
18 1100582c 061977bc 00000001 MSVBVM60!__vbaNew2+0x20

The call stacks for the other 3 worker threads is as follows
0602fa8c 77f83955 ntdll!ZwWaitForSingleObject+0xb
0602fb00 77f838c6 ntdll!RtlpWaitForCriticalSection+0x9e
0602fb08 6a9e7412 ntdll!RtlEnterCriticalSection+0x46
0602fd7c 6a9e6e06 MSVBVM60!TipUnloadProject+0x20
0602fd90 6a9e6b49 MSVBVM60!ProjFDeleteThread+0x6e
0602fdac 6aa5770c
MSVBVM60!CVBThreadAction::CleanupProjData+0x6c
0602fdbc 6aa0ee69
MSVBVM60!CThreadPool::CleanupAtDllDetach+0x14
0602fdd4 77f82fc9 MSVBVM60!UserDllMain_26+0x39
0602fdfc 77f84697 ntdll!LdrpCallInitRoutine+0x14
0602fe50 77e8762c ntdll!LdrShutdownThread+0xa3
0602feb8 004e88f6 KERNEL32!ExitThread+0x53
0602ff18 005618a6
WFExec!WFTaskExecuterThread::ThreadProc+0xbe
Click to expand...
[W:\bvAdminForWindows\Rules\Components\Workflow\WFCore\WFTaskExecuterThread.
cpp @ 63]
0602ff80 7800a3c0 WFExec!Thread::ThreadProc+0x47
[W:\bvAdminShared\Reusable\Components\REReusableLib\Thread.cpp @ 106]
0602ffb4 77e8758a MSVCRT!_beginthreadex+0xca
0602ffec 00000000 KERNEL32!BaseThreadStart+0x52


The hang does not occur if I make the threading model of the VB
components, single threaded instead of apartment thread. However, I need
them to be apartment threaded due to impersonation reasons.

Can someone please help me here?

Regards,
Madhu
Click to expand...
Click to expand...
 
M

Madhu Gopinathan

Hi Ivan,
Thanks for your immediate reply.
I tried '!cs' command in Windbg version 6.2.0007.4, but it returned "No
export !cs found". Do I have to load some helper dll like sieextpub.dll for
this export?

I figured the problem to be occuring because the VB component creates
some global apartment threaded objects on one of the worker threads, while
the other worker threads refer to the instances created on the first thread.
After task execution, the thread that created the global objects dies, while
the other threads that still refer to the global references to the objects
created on first thread, hang upon calls to that objects, (because they have
posted messages to the window of thread 1, while not getting response in
their message queue). I hope you understand the problem.

That is the reason why everything was working when I made the threading
model of the VB component "Single threaded" instead of "Apartment threaded",
because all objects were created on the main thread, which remained alive as
long as the process was executing.

But, I still don't understand how the Loader has been locked here? Can
you shed some light on the same? Do you think that the reason I think for
the hang is right and logical enough?

Thanks again.
Regards,
Madhu.


Ivan Brugiolo said:
Both the `!cs' and the `!locks' command are availalble.

Upon closer inspection, the VB runtime is most likely at fault,
since it's waiting for a critical section in the DllMain(THREAD_DETACH) code
path.
The loader lock is held while performing thread shutdown anyway, and then
the runtime is holding one more critical section.
The thread waiting on the LoaderLock inside LoadLibrary has an uncomplete
stack,
but most likely somewhere down the stack there is a code path
that holds the same critical section that is waited in the THREAD_DETACH
code path.

if you could report the output of the `~*kb 100' command in cdb/ntsd/windbg,
maybe there are more hints to support this thesis.

I'm not at all a VB expert, but maybe you can avoid this by preventing the
LoadLibrary call
somewhere in the "Project Startup" code-path.
Maybe there are certain restriction in causing the VB runtime to calll
LoadLibrary/GetProcaddress
in certain places of the VB code, the same way there are restrictions
about Loader-Lock sensitive options while holding other locks in the
traditional Win32.

--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm


Madhu Gopinathan said:
Hi Ivan,
Thanks for your quick response.
I did not come across any !cs command in windbg. Are you talking about
the !critlist command exported from the sieextpub.dll? If so, I do get a
deadlock situation sometimes, which tells me which thread is owning the
critical section that the others threads are blocking on. The two call
stacks I have given are those of the deadlocked threads.

However I cannot decipher any information from them because they
Click to expand...
seem
to
be deadlocking in the system DLLs. One on the call to ExitThread, while the
other in LoadLibrary(for Kernel32).

Can you help me to unmangle the call stack? Any help will be greatly
appreciated.

Thanks again,
Madhu.



manages
the
Click to expand...
some
VB is
Click to expand...
[W:\bvAdminForWindows\Rules\Components\Workflow\WFCore\WFTaskExecuterThread.
cpp @ 63]
0602ff80 7800a3c0 WFExec!Thread::ThreadProc+0x47
[W:\bvAdminShared\Reusable\Components\REReusableLib\Thread.cpp @ 106]
0602ffb4 77e8758a MSVCRT!_beginthreadex+0xca
0602ffec 00000000 KERNEL32!BaseThreadStart+0x52


The hang does not occur if I make the threading model of
Click to expand...
the
VB
components, single threaded instead of apartment thread. However, I need
them to be apartment threaded due to impersonation reasons.

Can someone please help me here?

Regards,
Madhu
Click to expand...
Click to expand...
Click to expand...
 
Top