Application crash caused by mscorwks RRS feed

  • Question

  • Hi,

    I've been trying to debug an issue that crashes my application.

    The issue is: faulting module name: mscorwks.dll, version: 2.0.50727.4927, time stamp:0x4a275a68.

    The application is a 32-bit VB6 executable and calls some c# (.net 2.0) classes through COM interop.  The c# code makes uses a asynchronous delegates in a few locations.  The crash cannot systematically be reproduced, but will happen from time to time.

    I've tried debugging the application with WinDbg but am not getting anywhere.  Some help would be appreciated.

    Here's the exception and call stack retrieved while debugging with WinDbg:

    (15e8.10d0): Unknown exception - code c000008f (first chance)
    (15e8.1258): Access violation - code c0000005 (first chance)
    First chance exceptions are reported before any exception handling.
    This exception may be expected and handled.
    eax=00000000 ebx=00000000 ecx=116308c0 edx=02000000 esi=0eb0e8c8 edi=0eb0e888
    eip=634d08c9 esp=0b02f814 ebp=0b02f820 iopl=0         nv up ei pl zr na pe nc
    cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010246
    634d08c9 f70000000800    test    dword ptr [eax],80000h ds:0023:00000000=????????

     # ChildEBP RetAddr  Args to Child             
    00 0b02f820 6345da22 0eb0e888 0b02ff34 00000000 mscorwks!WKS::gc_heap::c_promote_callback+0xcc
    01 0b02f838 6345e5a8 0b02ff00 0eb0e888 00000000 mscorwks!GcEnumObject+0x2d
    02 0b02f94c 6345db92 0b02fbd4 0b02f978 00000000 mscorwks!EECodeManager::EnumGcRefs+0x65c
    03 0b02f9a8 6341eff7 0a81a89c 0b02ff00 00000000 mscorwks!GcStackCrawlCallBack+0x1b7
    04 0b02f9bc 6341d7f5 0b02fa48 6345da8a 0b02ff00 mscorwks!Thread::MakeStackwalkerCallback+0x15
    05 0b02fba0 6341dc67 09fbf968 0b02ff00 6341dc67 mscorwks!Thread::StackWalkFramesEx+0x382
    06 0b02fbd0 00000000 00000000 0eb0e858 0eb0e854 mscorwks!Thread::StackWalkFrames+0xb8

    Pleas help, I'm at a loss as to what's going on.




    Tuesday, March 30, 2010 10:22 PM


All replies

  • This looks like managed heap corruption (http://blogs.msdn.com/tess/archive/2006/02/09/net-crash-managed-heap-corruption-calling-unmanaged-code.aspx). Those are not easy to diagnose.

    There's also option to use GCStress and PageHeap (if the repro is simple enough) - see the answer here: http://social.msdn.microsoft.com/Forums/en/clr/thread/0fcb5bb1-0cd8-40e4-96d9-f0cb8b6cdbdf


    Wednesday, March 31, 2010 2:13 AM
  • Hi Karel,

    Thank you for providing those links.  I've read them both and ran !verifyheap on my crash dump file (adplus -crash) and no errors were found.  Doesn't that rule out heap corruption?



    Wednesday, March 31, 2010 12:36 PM
  • I don't have much experience with GC, but I personally don't think that successful !verifyheap would mean that everything is OK. Otherwise CLR PSS would blog about it. Try GCStress as described in the above link.


    Wednesday, March 31, 2010 3:20 PM
  • Here's update from Maoni (our GC expert):
    !verifyheap not reporting errors just means the heap *itself* is consistent – eg, as we go through the heap linearly we didn’t find any object that has references to an invalid object. However, this doesn’t mean everyone who has a reference to a managed object is using that object correctly. In this case it’s reporting of a stack root.

    Overall running GCStress is probably the best thing you can do now. It will tell you more where the issue might originated. Of course it has quite big overhead and your application will be very slow when running with GCStress registry key turned on.


    Thursday, April 1, 2010 4:19 AM