none
Deadlock when starting up a WinForm application (advapi32!SddlSidLookupCritical and ntdll!LdrpLoaderLock) RRS feed

  • Question

  • Hi,

    When we start our system we boot several managed WinForm applications. When we updated to .NET 4.0 we started noticing that more often than not - one random application would not start. You could see it in the task manager but no UI were visible. 

    Running Debug Diagnostics Tool for a dump we got the following information.

    Detected a serious critical section related problem in process.dmp
    Lock at advapi32!SddlSidLookupCritical owned by thread 2 is Deadlocked with lock at ntdll!LdrpLoaderLock owned by thread 0

    So there seems to be a deadlock, but we cannot really see where. Any suggestions on how we can move forward with debugging this issue?

    Thread data below.

    Thread 0 - System ID 944

    This thread is not fully resolved and may or may not be a problem. Further analysis of these threads may be required.

    .NET Call Stack
    Function
    [[DebuggerClassInitMarkFrame]]

    Full Call Stack
    Function
    ntdll!KiFastSystemCallRet
    ntdll!ZwWaitForSingleObject+c
    ntdll!RtlpWaitForCriticalSection+132
    ntdll!RtlEnterCriticalSection+46
    advapi32!InitializeSidLookupTable+86
    advapi32!LocalConvertStringSDToSD_Rev1+78
    advapi32!ConvertStringSecurityDescriptorToSecurityDescriptorW+31
    advapi32!ConvertStringSecurityDescriptorToSecurityDescriptorA+4c
    msctf!CreateProperSecurityDescriptor+a6
    msctf!CCicSecAttr::operator _SECURITY_ATTRIBUTES *+38
    msctf!CCiceroSharedMem::Start+6c
    msctf!ProcessAttach+17b
    msctf!DllMain+39
    msctf!_DllMainCRTStartup+52
    ntdll!LdrpCallInitRoutine+14
    ntdll!LdrpRunInitializeRoutines+344
    ntdll!LdrpLoadDll+3e5
    ntdll!LdrLoadDll+230
    kernel32!LoadLibraryExW+18e
    user32!GetGUIThreadInfo+12d
    ntdll!KiUserCallbackDispatcher+13
    user32!GetScrollInfo+3a7
    user32!GetScrollInfo+460
    user32!CreateWindowExW+33
    ole32!InitMainThreadWnd+3c
    ole32!CoInitializeEx+112
    clr!Thread::SetApartment+16d
    clr!SystemDomain::SetThreadAptState+90
    clr!SystemDomain::ExecuteMainMethod+181
    [[DebuggerClassInitMarkFrame]]
    clr!ExecuteEXE+58
    clr!_CorExeMainInternal+19f
    clr!_CorExeMain+4e
    mscoreei!_CorExeMain+38
    mscoree!ShellShim__CorExeMain+99

    mscoree!_CorExeMain_Exported+8

    Thread 2 - System ID 7104

    This thread is waiting on critical section ntdll!LdrpLoaderLock owned by thread 0.
    Thread 0 in turn is deadlocked with another thread.


    .NET Call Stack
    Function

    Full Call Stack
    Function
    ntdll!KiFastSystemCallRet
    ntdll!ZwWaitForSingleObject+c
    ntdll!RtlpWaitForCriticalSection+132
    ntdll!RtlEnterCriticalSection+46
    ntdll!LdrLockLoaderLock+ea
    ntdll!LdrLoadDll+d6
    kernel32!LoadLibraryExW+18e
    kernel32!LoadLibraryW+11
    rpcrt4!PerformRpcInitialization+e6
    rpcrt4!RpcStringBindingComposeW+14
    advapi32!RpcpBindRpc+19f
    advapi32!PLSAPR_SERVER_NAME_bind+18
    rpcrt4!GenericHandleMgr+a0
    rpcrt4!ExplicitBindHandleMgr+44
    rpcrt4!NdrClientCall2+d3
    advapi32!LsarOpenPolicy2+1b
    advapi32!LsaOpenPolicy+95
    advapi32!InitializeSidLookupTable+ea
    advapi32!LocalConvertStringSDToSD_Rev1+78
    advapi32!ConvertStringSecurityDescriptorToSecurityDescriptorW+31
    clr!ProfilingAPIAttachDetach::GetSecurityDescriptor+1c1
    clr!ProfilingAPIAttachDetach::InitSecurityAttributes+13
    clr!ProfilingAPIAttachDetach::InitializeForOnDemandMode+6a
    clr!ProfilingAPIAttachDetach::GetAttachEvent+1c
    clr!Thread::intermediateThreadProc+4b
    kernel32!BaseThreadStart+37

    Monday, July 6, 2015 10:44 AM

All replies

  • Hi Vonlochow,

    Can you test these WinForm apps on another machines, this will help us to see if this is a common issue or a special issue on a special machine. If the test leads to that machine, try restart or repair it.

    If problem happens on other machines, we have to do more tests to narrow it down.  If we run app independently on that machine in startup, can you see the problem? If we boot several blank WinForm apps, can it happen?

    In short, I cannot provide helpful suggestions if there is not enough info. Please try to find more and post them here.

    Regards,


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Tuesday, July 7, 2015 3:02 AM
    Moderator
  • Thread 0 is initializing a COM STA, which requires creating a window. This somehow causes user32.dll to load msctf.dll, so thread 0 is holding LdrpLoaderLock. The DllMain of msctf.dll then tries to look up some SIDs and ends up waiting for SddlSidLookupCritical held by thread 2.

    Thread 2 too is looking up some SIDs and has entered SddlSidLookupCritical, which presumably guards some lookup table that has not yet been initialized.  It then tries to load some RPC library and ends up waiting for LdrpLoaderLock held by thread 0.

    I think it is a bug in msctf.dll that its DllMain indirectly calls such a risky function in advapi32.  Which version of Windows is this?

    I think you could probably avoid the deadlock by ensuring that the SID lookup table and RPC are fully initialized before msctf.dll is loaded. First change your program to start the Main method in MTA so that COM does not create a window and you can run managed code without loading msctf.dll. Then do some kind of SID lookup there so that the SID lookup table is initialized; the System.Security.AccessControl.RawSecurityDescriptor(string) constructor looks promising. Finally start another thread in the STA (using Thread.SetApartmentState) and run the user interface there.

    Wednesday, July 8, 2015 5:28 PM
  • It is running "Windows Embedded POSReady 2009". 

    We have verified that this is only happening for .NET 4.0 applications. If we downgrade to .NET 3.5 it all works fine again. 

    Thursday, July 16, 2015 6:37 AM
  • I have some Windows Forms applications built against .NET Framework 4.0 here.  I debugged one of them with WinDbg on Windows 7 SP1 with .NET Framework 4.5.2 installed, set a deferred breakpoint on clr!ProfilingAPIAttachDetach::GetAttachEvent, did "sxe ld:msctf" so that the debugger breaks when msctf.dll is loaded, and did "sxe ct" so that the debugger breaks if a thread is created.  When I started the application, it loaded msctf.dll from within USER32!UserClientDllInitialize. The application had not yet created any other threads and had not reached the clr!ProfilingAPIAttachDetach::GetAttachEvent breakpoint.  Therefore, I think a deadlock similar to yours cannot occur on Windows 7 SP1; it is specific to Windows Embedded POSReady 2009.  Perhaps it could also occur on Windows XP SP3, but Microsoft no longer supports that.

    If you try the MTA workaround I suggested, please report whether it works.

    Thursday, July 16, 2015 8:01 PM
  • The problem is that I don't even reach the first line of code in the winform. Nothing of our C# code executes before running into the deadlock. 

    If I understand your fix suggestion it requires us to actually reach the C# code first?

    Tuesday, July 21, 2015 4:40 AM
  • Nothing of our C# code executes before running into the deadlock.

    Right, that's why I suggested using MTA. Your stack trace shows that CoInitializeEx is creating a window, which I think means the thread is trying to enter a STA. If the thread entered the MTA instead, then CoInitializeEx should not create a window, and you might be able to run C# code without loading msctf.dll.

    Do you have an STAThreadAttribute in the Main method now?

    Tuesday, July 21, 2015 8:02 PM
  • Ah - I see. Let me try it and get back to you.

    Wednesday, July 22, 2015 7:05 AM