access violation in gc_heap::mark_object_simple RRS feed

  • Question

  • My windows service is crashing in production, seemingly randomly.  It's a 32-bit .NET Framework 3.5 app, running as a service on a Windows Server 2003 machine.  My client has sent me a few crash dumps generated using ADPlus.  Windbg shows the following stack trace for the exception:

    ChildEBP RetAddr  Args to Child             
    0709fef0 79f7b47e 089b972c 090ae514 006c7f94 mscorwks!WKS::gc_heap::mark_object_simple1+0x148
    0709ff1c 79f472d5 03d13a70 00000000 79f769cf mscorwks!WKS::gc_heap::mark_object_simple+0x2b4
    0709ff50 79f46d81 00000002 00000000 00000000 mscorwks!WKS::gc_heap::c_drain_mark_list+0x95
    0709ff7c 79f47773 7a3b9010 7a3b9028 0709ffb0 mscorwks!WKS::gc_heap::c_mark_phase+0xaa
    0709ff98 79f82425 00000000 00000000 00000000 mscorwks!WKS::gc_heap::gc1+0x59
    0709ffb0 79f82477 00000000 77e6482f 00000000 mscorwks!WKS::gc_heap::gc_thread_function+0x9f
    0709ffb8 77e6482f 00000000 00000000 00000000 mscorwks!WKS::gc_heap::gc_thread_stub+0x73
    0709ffec 00000000 79f82448 00000000 00000000 kernel32!BaseThreadStart+0x34

    Everything I can find about errors similar to this indicate that the managed heap is corrupted, but !verifyheap produces no output other than "-verify will only produce output if there are errors on the heap".  Running "!help verifyheap" tells me that "If this gc heap corruption exists, there is a serious bug in your own code or in the CLR. In user code, an error in constructing PInvoke calls can cause this problem, and running with Managed Debugging Assistants is advised. If that possibility is eliminated, consider contacting Microsoft Product Support for help."  The lack of heap corruption output leads me to believe that some incorrect interop is not corrupting my heap, but just in case, the only interop performed by my application (that I know of) is done by SharpPcap (version 3.2), against winpcap 4.1.2.  It also uses MySQL Connector .NET version 6.3.5.

    !analyze -v doesn't provide me with anything that I know how to use to track it down either.  So, I'm stumped.  I'd be happy to post or send any additional windbg output or other information that may help track this down.

    Thursday, October 28, 2010 7:19 PM

All replies

  • Hi,

    Could you send me a copy of the dump file? if so, please let me know your email address by sending a mail to Then I will create a file transfer workspace where you can upload your dump file. The dump will be kept confidential.

    MSDN Subscriber Support in Forum
    If you have any feedback of our support, please contact
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Friday, October 29, 2010 3:54 AM
  • The managed heap seems to be inconsistent. Usually in such cases, an invalid pinvoke call can result in such problem + other issues. We may need to get the dump files with GCStress enabled and then the dumps would make more sense.  That said, from a support perspective this is really beyond what we can do here in the forums. If you cannot determine your answer here or on your own, consider opening a support case with us. Visit this link to see the various support options that are available to better meet your needs:;en-us;offerprophone.

    --Trevor H.
    Send files to "MS_TREVORH"
    Check out the Microsoft CTS TFS BLOG:
    Monday, November 1, 2010 4:46 PM
  • I can probably get dump files with GCStress enabled.  I haven't been able to find any documentation regarding GCStress... all I've seen is this, which mentions four registry keys and full page heap using gflags.  Do I also need to provide my client with a Debug build of the app, or will GCStress work with a Release build?
    Tuesday, November 2, 2010 4:14 PM