Re: LoadLibrary race/deadlock

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

From: Henry Markov (jnhblhr_at_yahoo.com)
Date: 11/29/04 

Date: Mon, 29 Nov 2004 16:07:23 -0500

Back from the long holiday weekend. Here is the call stack for the deadlocked
thread:

0:000> k
ChildEBP RetAddr
0012f518 7c90e234 ntdll!KiFastSystemCallRet
0012f51c 7c8110db ntdll!NtQueryVolumeInformationFile+0xc
*** WARNING: Unable to verify checksum for C:\Program Files\Lucent\libmmd.dll
*** ERROR: Symbol file could not be found. Defaulted to export symbols for
C:\Program Files\Lucent\libmmd.dll -
0012f54c 00bed79a kernel32!GetFileType+0x7e
WARNING: Stack unwind information not available. Following frames may be wrong.
0012f5ac 00becb8d libmmd!matherrl+0x10b6dd
0012f5d0 7c9011a7 libmmd!matherrl+0x10aad0
0012f5f0 7c91cbab ntdll!LdrpCallInitRoutine+0x14
0012f6f8 7c916178 ntdll!LdrpRunInitializeRoutines+0x344
0012f9a4 7c9162da ntdll!LdrpLoadDll+0x3e5
0012fc4c 7c801bb9 ntdll!LdrLoadDll+0x230
0012fcb4 7c801d6e kernel32!LoadLibraryExW+0x18e
0012fcc8 7c801da4 kernel32!LoadLibraryExA+0x1f
*** WARNING: Unable to verify checksum for C:\Program Files\Lucent\encoder.exe
*** ERROR: Module load completed but symbols could not be loaded for C:\Program
Files\Lucent\encoder.exe
0012fce4 0040162c kernel32!LoadLibraryA+0x94
0012fcf0 00402e92 encoder+0x162c
0012fd8c 00403ee0 encoder+0x2e92
0012ff80 00404f97 encoder+0x3ee0
0012ffc0 7c816d4f encoder+0x4f97
0012fff0 00000000 kernel32!BaseProcessStart+0x23

"Jonathan Morrison [MSFT]" wrote:
>
> Can you include the callstack for that thread by using the 'k' command?
>
> --
> 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
> "Henry Markov" <jnhblhr@yahoo.com> wrote in message
> news:41A4EE59.70E80BD3@yahoo.com...
> > Pavel and Jonathan,
> > Thanks for the responses. I've done software development for 30+ years
> > but very
> > little in the Windows domain therefore most of your information was new to
> > me.
> > Here is the log from my debug session:
> >
> > Opened log file 'c:\enclog'
> > 0:000> !locks
> >
> > CritSec ntdll!LdrpLoaderLock+0 at 7C97C0D8
> > LockCount 2
> > RecursionCount 2
> > OwningThread fd4
> > EntryCount 1
> > ContentionCount 1
> > *** Locked
> >
> > Scanned 145 critical sections
> > 0:000> ~~[fd4]s
> > eax=00000075 ebx=000000e8 ecx=00000010 edx=0007e3e2 esi=003f22c0
> > edi=000000e8
> > eip=7c90eb94 esp=0012f51c ebp=0012f54c iopl=0 nv up ei pl zr na po
> > nc
> > cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000
> > efl=00000246
> > ntdll!KiFastSystemCallRet:
> > 7c90eb94 c3 ret
> > Closing open log file c:\enclog
> >
> > I suppose this verifies a deadlock but the information about thread ID fd4
> > appears to be mostly register and condition code values that don't tell me
> > much. Is there something in this information that is clearly important?
> >
> > Note that I have been told that the DLL that I am invoking does not have a
> > DllMain. Does anything in the output suggest that libmmd.dll is
> > implicated in
> > the deadlock? To repeat, an earlier version of the DLL compiled with VC6
> > never
> > exhibited this race/deadlock. It started immediately after switching to
> > the
> > Intel compiler which we want to use because of its Pentium-M
> > optimizations. The
> > Intel compiler, but not VC6, creates a dependency on libmmd.dll.
> >
> > HM
> >
> > Pavel Lebedinsky wrote:
> >>
> >> When the program hangs, attach to it with windbg/cdb and run
> >> these commands:
> >>
> >> 0:000> .symfix c:\symbols
> >> 0:000> .reload
> >> 0:000> !locks
> >>
> >> Most likely your problem is caused by somebody holding the loader
> >> lock, so you should see something like this in the output:
> >>
> >> CritSec ntdll!LdrpLoaderLock+0 at 7C97C0D8
> >> LockCount 0
> >> RecursionCount 1
> >> OwningThread a08
> >> EntryCount 0
> >> ContentionCount 0
> >> *** Locked
> >>
> >> You can then switch to the thread that holds the lock (in this
> >> case it's thread id 0xa08) and check what it is doing:
> >>
> >> 0:000> ~~[a08]s
> >> 0:000> k

Relevant Pages