.NET 4.5: Interner Fehler in der .NET Runtime (80131506) / gleichzeitige GC deaktivieren

Ich habe ein Dauerbrenner .NET 4.5-Anwendung stürzt ab, nach dem Zufallsprinzip, und die Nachricht, die ich erwähnt habe in der Frage-Titel in der event log. Das Problem ist reproduziert auf 3 verschiedenen Rechnern und 2 verschiedenen Systemen (2008 R2 und 2012). Anwendung nicht verwenden unsichere/nicht verwaltete Komponenten, die es rein geschafft .NET, nur mit dem nicht verwalteten Sache der CLR selbst.

Hier ist der stack-trace von der Absturzstelle habe ich extrahiert aus dem 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    

Diesem Thema eng ähnelt dem, was besprochen wurde hier, also versuchte ich die Lösungsvorschläge in diesem Thema, aber keiner von Ihnen geholfen:

• Habe ich versucht, die Installation von diese hotfix, aber es nicht installieren auf meinen Maschinen (KB2640103 nicht gilt, oder blockiert ist, durch eine andere Bedingung auf Ihrem computer), das macht eigentlich Sinn, denn ich bin mit 4.5, nicht 4.0.
• Ich habe versucht, das deaktivieren concurrent-GC und/oder die Aktivierung von server-GC. Jetzt den relevanten Teil meiner app.config sieht wie folgt aus:

  <?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>

Aber die seltsame Sache ist ich finde immer noch mehrere GC-bezogenen threads in der dump-Prozess. Neben der, den der Absturz Auftritt, gibt es 7 threads mit dem folgenden 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    

Das macht mich Frage mich, ob ich irgendwie Schrauben die Deaktivierung des gleichzeitigen GC (das ist, was ich eigentlich aufgeführt der config).

Ich glaube, die wraps, was ich habe es geschafft so weit. Ich könnte wirklich etwas Hilfe gebrauchen, wie Sie Vorgehen mit den Umgang mit diesem Thema.

InformationsquelleAutor der Frage HellBrick | 2013-10-03