none
What can cause this hang? RRS feed

  • Question

  • I am investigaing a DW APPLICATION_BUSY_HANG minidump. WinDbg shows the main thread stack trace like below. Does anybody know what could possibly cause this hang? The code seems not waiting on anything.

    Thanks

    ChildEBP RetAddr 
    0012ee68 79fcc91f mscorwks!MethodTableBuilder::EnumerateClassMethods+0x823 [f:\dd\ndp\clr\src\vm\class.cpp @ 3426]
    0012ef2c 79fcd1fd mscorwks!MethodTableBuilder::BuildMethodTableThrowing+0x5f3 [f:\dd\ndp\clr\src\vm\class.cpp @ 2050]
    0012f16c 79e92140 mscorwks!ClassLoader::CreateTypeHandleForTypeDefThrowing+0x863 [f:\dd\ndp\clr\src\vm\clsload.cpp @ 4381]
    0012f1bc 79e9136a mscorwks!ClassLoader::CreateTypeHandleForTypeKey+0xba [f:\dd\ndp\clr\src\vm\clsload.cpp @ 3286]
    0012f2ec 79e914ba mscorwks!ClassLoader::DoIncrementalLoad+0xa7 [f:\dd\ndp\clr\src\vm\clsload.cpp @ 3172]
    0012f384 79e915da mscorwks!ClassLoader::LoadTypeHandleForTypeKey_Inner+0x12c [f:\dd\ndp\clr\src\vm\clsload.cpp @ 3767]
    0012f3f4 79e91203 mscorwks!ClassLoader::LoadTypeHandleForTypeKey_Body+0x1da [f:\dd\ndp\clr\src\vm\clsload.cpp @ 3908]
    0012f44c 79e91f8b mscorwks!ClassLoader::LoadTypeHandleForTypeKey+0xae [f:\dd\ndp\clr\src\vm\clsload.cpp @ 3667]
    0012f4b8 79e9a9fb mscorwks!ClassLoader::LoadTypeDefThrowing+0x193 [f:\dd\ndp\clr\src\vm\clsload.cpp @ 2608]
    0012f518 79e89068 mscorwks!ClassLoader::LoadTypeDefOrRefThrowing+0x1da [f:\dd\ndp\clr\src\vm\clsload.cpp @ 2776]
    0012f624 79f991cc mscorwks!SigPointer::GetTypeHandleThrowing+0x95d [f:\dd\ndp\clr\src\vm\siginfo.cpp @ 1524]
    0012f670 79f991f2 mscorwks!CEECompileInfo::DecodeType+0x55 [f:\dd\ndp\clr\src\vm\compile.cpp @ 1754]
    0012f68c 79f98488 mscorwks!CORCOMPILE_TYPE_HANDLE_TABLE_TokenLoader+0x1f [f:\dd\ndp\clr\src\vm\jitinterface.cpp @ 10627]
    0012f6a4 79f9832c mscorwks!LoadDynamicInfoEntry+0x19 [f:\dd\ndp\clr\src\vm\jitinterface.cpp @ 11038]
    0012f6cc 79f982cb mscorwks!Module::FixupNativeEntry+0x51 [f:\dd\ndp\clr\src\vm\ceeload.cpp @ 9864]
    0012f6f4 79f98203 mscorwks!Module::FixupDelayListAux<Module *,void (__thiscall Module::*)(enum CorCompileTokenTable,unsigned long *),PEImageLayout>+0x52 [f:\dd\ndp\clr\src\vm\ceeload.inl @ 454]
    0012f754 79e81363 mscorwks!MethodDesc::DoPrestub+0x2ba [f:\dd\ndp\clr\src\vm\prestub.cpp @ 1120]
    0012f7a4 00971efe mscorwks!PreStubWorker+0xf3 [f:\dd\ndp\clr\src\vm\prestub.cpp @ 722]
    WARNING: Frame IP not in any known module. Following frames may be wrong.
    0012f7ec 79f68c4e 0x971efe
    0012f8a0 79f68d5b mscorwks!COMToCLRWorkerBody+0x1de [f:\dd\ndp\clr\src\vm\comtoclrcall.cpp @ 476]

    jianxu
    Saturday, January 10, 2009 12:51 AM

All replies

  • What is the mscorwks.dll version? Without that it's hard to guess ...
    -Karel
    Saturday, January 10, 2009 8:41 AM
    Moderator
  • That's a scary statement.  It is mapping a COM interface method call to a managed call.  That should never hang, there would be heap corruption if it does.  Don't forget to look at all the threads.
    Hans Passant.
    Saturday, January 10, 2009 11:19 AM
    Moderator
  • nobugz said:

    That's a scary statement.  It is mapping a COM interface method call to a managed call.  That should never hang, there would be heap corruption if it does.  Don't forget to look at all the threads.


    Hans Passant.



    That's what I don't understand -- The main thread stack does not look like hanging. Application_Hang indicates the main thread was not responding to messages, right? Other threads busy hanging or in dead locks should not make the application hang. What should I suspect here? Could it be that the main thread was in an infinate loop?

    jianxu
    Monday, January 12, 2009 9:43 PM
  • Karel Zikmund - MSFT said:

    What is the mscorwks.dll version? Without that it's hard to guess ...
    -Karel

    This was from VCExpress 2008 SP1. Mscorwks.dll version 2.0.50727.3053 (netfxsp.050727-3000).
    jianxu
    Monday, January 12, 2009 9:45 PM