.NET 4.5: internal error in the .NET Runtime (80131506) / disabling concurrent GC

Question

I have a long-running .NET 4.5 application that crashes randomly, leaving the message I've mentioned in the question title in the event log. The issue is reproduced on 3 different machines and 2 different systems (2008 R2 and 2012). Application doesn't use any unsafe/unmanaged components, it's pure managed .NET, with the only unmanaged thing being the CLR itself.

Here's the stack trace of the crash site that I've extracted from the dump:

clr.dll!MethodTable::GetCanonicalMethodTable()  
clr.dll!SVR::CFinalize::ScanForFinalization()  - 0x1a31b bytes  
clr.dll!SVR::gc_heap::mark_phase()  + 0x328 bytes   
clr.dll!SVR::gc_heap::gc1()  + 0x95 bytes   
clr.dll!SVR::gc_heap::garbage_collect()  + 0x16e bytes  
clr.dll!SVR::gc_heap::gc_thread_function()  + 0x3e bytes    
clr.dll!SVR::gc_heap::gc_thread_stub()  + 0x77 bytes    
kernel32.dll!BaseThreadInitThunk()  + 0x1a bytes    
ntdll.dll!RtlUserThreadStart()  + 0x21 bytes    

This issue closely resembles the one that was discussed here, so I tried the solutions suggested in that topic, but none of them helped:

• I've tried installing this hotfix, but it won't install on any of my machines (KB2640103 does not apply, or is blocked by another condition on your computer), which actually makes sense, because I'm using 4.5, not 4.0.

• I've tried disabling concurrent GC and/or enabling server GC. Right now the relevant part of my app.config looks like this:

  <?xml version="1.0"?>
  <configuration>        
      <runtime>
          <gcConcurrent enabled="false"/>
          <gcServer enabled="true" />
      </runtime>
  <startup><supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5"/>    </startup></configuration>
  

Though the weird thing is I still find multiple GC-related threads in the process dump. Besides the one the crash occurs in, there are 7 threads with the following stack trace:

ntdll.dll!NtWaitForSingleObject()  + 0xa bytes  
KERNELBASE.dll!WaitForSingleObjectEx()  + 0x9a bytes    
clr.dll!CLREventBase::WaitEx()  + 0x13f bytes   
clr.dll!CLREventBase::WaitEx()  + 0xf7 bytes    
clr.dll!CLREventBase::WaitEx()  + 0x78 bytes    
clr.dll!SVR::t_join::join()  + 0xd8 bytes   
clr.dll!SVR::gc_heap::scan_dependent_handles()  + 0x65 bytes    
clr.dll!SVR::gc_heap::mark_phase()  + 0x347 bytes   
clr.dll!SVR::gc_heap::gc1()  + 0x95 bytes   
clr.dll!SVR::gc_heap::garbage_collect()  + 0x16e bytes  
clr.dll!SVR::gc_heap::gc_thread_function()  + 0x3e bytes    
clr.dll!SVR::gc_heap::gc_thread_stub()  + 0x77 bytes    
kernel32.dll!BaseThreadInitThunk()  + 0x1a bytes    
ntdll.dll!RtlUserThreadStart()  + 0x21 bytes    

Which makes me wondering if I could somehow screw up disabling the concurrent GC (that's what I actually listed the config for).

I think that wraps up what I've managed to find so far. I could really use some help on how to proceed with dealing with this issue.

Answer 1

I am drawing from my past experience in our application. This could be caused if an exception goes unhandled till the Finalizer level, and if it goes... it will crash the application.

Before doing anything on the GC configuration..

One quick check... Are you using task parallel libraries?. If yes make sure you are handling exceptions properly. If exceptions from different threads are left unhandled it goes till Finalizer which then crashes the application. There are couple of ways to handle them neatly. Handling 'Aggregate' Exception is one way (that we used to solve!).

http://msdn.microsoft.com/en-us/library/dd537614.aspx

I don't have 50 points to add a comment, so adding it as an answer...

Answer 2

I realize this is an old post, however, I ran into the same issue as the OP. The point atlaste made:

Change the runtime to x86 or x64 and try again; you can also mess with the concurrent GC settings like you already tried.

Was the key for me. All of my projects were set to Any CPU except for one (coincidentally the entry point for the application which is a Console Application project). This project was set to x86. Once I changed it to Any CPU the application ran correctly.

Answer 3

My problem is weird byt every 5-10 minutes my application pool kept crashing with this exit code (80131506). I'm not sure in high threaded operation / schedule task you should thrust the Garbage Collector, but the following solution worked for here.

I added a Job that calls GC.GetTotalMemory(true) every minute. I assume that, for some reason, the GC is not automatically calling the Garbage Collector often enough for the high number of disposable objects that I use. But this fix my problem! It's more like a quick fix than a final solution ;)