I got a crashdump generated by drwtsn32 on site, which show that the application is blocked while invoking system API FreeLibrary. Here's the class stack:
ChildEBP RetAddr Args to Child
06f0fc14 7c827d29 7c83d266 00000718 00000000 ntdll!KiFastSystemCallRet (FPO: [0,0,0])
06f0fc18 7c83d266 00000718 00000000 00000000 ntdll!ZwWaitForSingleObject+0xc (FPO: [3,0,0])
06f0fc54 7c83d2b1 00000718 00000004 00000000 ntdll!RtlpWaitOnCriticalSection+0x1a3 (FPO: [2,7,4])
06f0fc74 7c839874 7c8897a0 00000000 00000000 ntdll!RtlEnterCriticalSection+0xa8 (FPO: [1,1,0])
06f0fd7c 77e6b1bb 014e0000 00000000 02a67430 ntdll!LdrUnloadDll+0x35 (FPO: [SEH])
06f0fd90 005e8cdd 014e0000 02a4bc88 06f0fdbc kernel32!FreeLibrary+0x41 (FPO: [1,0,0])
....
I noticed the line ntdll!RtlEnterCriticalSection+0xa8 (FPO: [1,1,0]), and I think this should be critical_section relative. So I used dt command in windbg to show the CRITICAL_SECTION information about it
0:037> dt 7c8897a0 RTL_CRITICAL_SECTION
SiteAdminSvc!RTL_CRITICAL_SECTION
+0x000 DebugInfo : 0x7c8897c0 _RTL_CRITICAL_SECTION_DEBUG
+0x004 LockCount : -18
+0x008 RecursionCount : 1
+0x00c OwningThread : 0x00002098
+0x010 LockSemaphore : 0x00000718
+0x014 SpinCount : 0
the line +0x00c OwningThread : 0x00002098 show that critical_section was held by thread 0x2098, but it's so strange that I can't even find such a thread in thread list.
Is there any other method to find out why FreeLibrary get blocked ?
PS: there is an another story about the hung. If I debug the application using remote debugger, no hung is met. But if I start the application on the server machine. it does Thanks very much
I'm assuming you are calling FreeLibrary at a disallowed moment in time (like DllMain)
Why not call FreeLibrary from entry point function?
MSDN: loaderLock MDA
> However, I apparently cannot call FreeLibrary from the DllMain PROCESS_DETACH event
User contributions licensed under CC BY-SA 3.0