Aplikasi Mogok Dengan "Kesalahan Internal Dalam .NET Runtime"

112

Kami memiliki aplikasi yang ditulis terhadap .NET 4.0 yang selama akhir pekan mengalami crash, menempatkan pesan berikut ke dalam log peristiwa:

Aplikasi: Kerangka PnrRetrieverService.exe Versi: v4.0.30319
Deskripsi: Proses dihentikan karena kesalahan internal di .NET Runtime di IP 791F9AAA (79140000) dengan kode keluar 80131506.

Ini ada di kotak Windows Server 2003 R2 Edisi Standar. Googling kesalahan ini belum menemukan apapun yang berhubungan. Misalnya, ini tidak terjadi di VS Studio, melainkan di kotak produksi; ketika layanan akhirnya dimulai ulang, tidak ada masalah lagi.

Bagaimana cara mendiagnosis bug di .NET Runtime?

ALEXintlos
sumber
1
Jika ini adalah pertama kalinya kesalahan ini terjadi, saya akan memeriksa apa pun yang telah berubah dalam beberapa hari hingga satu minggu terakhir.
Tony Abrams

Jawaban:

121

dengan kode keluar 80131506

Itu buruk, ExecutionEngineException. Dimulai dengan .NET 4.0, pengecualian ini segera menghentikan program. Penyebab umum adalah korupsi keadaan tumpukan sampah yang dikumpulkan. Yang pada gilirannya selalu disebabkan oleh kode yang tidak terkelola. Lokasi yang tepat dalam kode tempat pengecualian ini dimunculkan tidak membantu, kerusakan biasanya terjadi jauh sebelum kerusakan terdeteksi.

Menemukan penyebab pasti untuk ini akan sulit. Tinjau kode tidak terkelola yang mungkin digunakan layanan Anda. Curigai masalah lingkungan jika tidak ada kandidat yang jelas, pemindai malware yang berperilaku buruk terkenal kejam. Jika terulang dengan sangat buruk maka curigai masalah perangkat keras seperti kesalahan RAM lunak.

Hans Passant
sumber
3
Saya memiliki masalah dengan SQL CE 3.5 yang merusak heap, menyebabkan pengecualian pada kesalahan runtime ntdll.dll dan .NET.
Phil
4
Mereka tercantum dalam file header SDK CorError.h
Hans Passant
2
Bagaimana Anda tahu mereka terdaftar di CorError.h ??
Yeonho
6
Gunakan alat Err.exe ini microsoft.com/en-au/download/details.aspx?id=985 untuk mengetahui apa arti kode kesalahan hex seperti 80131506 dan file header mana yang memuatnya.
Jeremy Thompson
2
@HansPassant Saya rasa pertanyaan yang dimaksud adalah 'dari semua file yang ada di dunia, bagaimana Anda tahu bahwa CorError.h adalah file yang berharga untuk dilihat'?
bacar
41

Bug dalam implementasi bersamaan dari Pengumpulan Sampah di x64 .Net 4 dapat menyebabkan ini seperti yang dinyatakan di entri microsoft KB berikut:

ExecutionEngineException terjadi selama Pengumpulan Sampah

Anda harus melakukan eksplorasi minidump dalam-dalam terlebih dahulu untuk memastikan bahwa masalah terjadi selama pengumpulan Sampah.

Lokasi minidump biasanya dapat ditemukan di entri Windows Error Reporting di event log setelah entri crash. Kemudian, bersenang-senanglah dengan WinDbg!

Dokumentasi terbaru tentang penggunaan <gcConcurrent/>elemen konfigurasi, untuk menonaktifkan pengumpulan sampah latar belakang bersamaan atau (di .NET 4 dan yang lebih baru), dapat ditemukan di sini .

thinkbeforecoding
sumber
terima kasih atas komentar ini - ini adalah solusi untuk masalah yang sudah lama saya alami!
lenniep
1
Anda seorang penyelamat, ini adalah masalah bagi kami. Selain itu, Anda juga dapat membuka file minidump di Visual Studio, mengatur lintasan simbol jika perlu, dan kemudian melakukan debug. Ini memberi tahu kami bahwa kesalahan terjadi di clr.dll! WKS :: gc_heap :: mark_object_simple (). Saya yakin WinDbg sangat kuat tetapi menggunakan VS dapat memberi tahu Anda cukup jika Anda hanya memverifikasi sumber kesalahan.
Tim
Aplikasi macet tetapi saya tidak menemukan mini dumps di folder C: \ Temp \ CrashDump. Ada beberapa tempat pembuangan sampah lain di sana, dan kami dapat menemukan sampah dari kecelakaan tersebut beberapa hari yang lalu. Tahukah Anda mengapa tidak ada crash dumps? Pesan kesalahan dan kode keluarnya persis sama.
Jeffrey Zhao
Ini persis seperti yang saya cari ... peristiwa kerusakan aplikasi berisi penunjuk instruksi, yang tidak berguna bagi saya tanpa dump. Tak terpikir untuk mencari acara nanti. Terima kasih!
laindir
1
Bagi orang lain dalam situasi yang sama, mungkin berguna untuk mengonfigurasi Pelaporan Kesalahan Windows untuk melakukan heap dump penuh saat macet: msdn.microsoft.com/en-us/library/windows/desktop/…
laindir
9

Saya telah mengalami "kesalahan internal" dalam runtime .NET yang ternyata disebabkan oleh bug dalam kode saya; jangan berpikir bahwa hanya karena itu adalah "kesalahan internal" dalam waktu proses .NET sehingga tidak ada bug dalam kode Anda sebagai penyebab utama. Selalu selalu menyalahkan kode Anda sendiri sebelum Anda menyalahkan kode orang lain.

Mudah-mudahan Anda memiliki informasi logging dan pengecualian / pelacakan tumpukan untuk mengarahkan Anda ke mana harus mulai mencari, atau bahwa Anda dapat mengulangi status sistem sebelum crash.

jason
sumber
7

Bagi mereka yang tiba di sini dari google, saya akhirnya menemukan pertanyaan SO ini , dan jawaban khusus ini memecahkan masalah saya. Saya telah menghubungi Microsoft untuk hotfix melalui obrolan langsung di support.microsoft.com dan mereka mengirimi saya tautan ke hotfix melalui email.

johnildergleidisson
sumber
5

Setelah bertahun-tahun bergumul dengan masalah ini di sejumlah aplikasi, tampaknya Microsoft akhirnya menerimanya sebagai bug di .NET 4 CLR yang menyebabkan hal ini terjadi. http://support.microsoft.com/kb/2640103 .

Saya sebelumnya telah "memperbaikinya" dengan memaksa pengumpul sampah untuk berjalan dalam mode server (gcServer enabled = "true" di app.config) seperti yang dijelaskan di artikel Microsoft yang ditautkan oleh Think Before Coding. Ini pada dasarnya memaksa semua utas dalam aplikasi untuk berhenti sementara selama pengumpulan menghapus kemungkinan utas lain mengakses memori yang dimanipulasi oleh GC. Saya senang menemukan bahwa bertahun-tahun saya sia-sia mencari "bug" dalam kode saya atau pustaka yang tidak dikelola pihak ke-3 lainnya tidak membuahkan hasil karena bug tersebut ada di kode Microsoft, bukan milik saya.

park896
sumber
1
Berapa nomor versi file HotFix yang Anda terima? Nomor versi yang tercantum di KB adalah 4.0.30319.526 tetapi saya sudah memiliki 4.0.30319.18052. Apakah HotFix masih diperlukan atau telah digulung menjadi Pembaruan Windows?
Otomatiskan
1
Ketika saya menjalankan exe HotFix saya mendapatkan "KB2640103 tidak berlaku, atau diblokir oleh kondisi lain di komputer Anda."
Otomatiskan
3

Memiliki kesalahan yang sama persis pada kotak WinXP dengan build terbaru dari kode .NET 4 saya. Memeriksa bangunan sebelumnya - sekarang mereka juga mogok! Ok, jadi bukan aku :). Tidak ada saran di sini / di atas yang membantu.

Laporan yang jauh lebih baru (2018-05-09) dari masalah yang sama: Aplikasi Crash dengan kode keluar 80131506 .

J : Kami menerima kesalahan serupa, tapi kami yakin kesalahan kami disebabkan oleh pengoptimal memori Citrix.
Penyelesaiannya adalah untuk memaksa regenerasi pustaka inti .Net pada host tempat masalah terjadi:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\ngen.exe update /force

Akar masalah masih belum diketahui (mesin tidak diperbarui dan hanya memiliki sedikit kegunaan), tetapi itu berhasil untuk saya !

Astrogator
sumber
2

Dalam kasus saya, pengecualian ini terjadi ketika ruang disk habis dan .NET tidak dapat mengalokasikan memori di Memori Virtual Windows.

Dalam event log saya melihat kesalahan ini:

Popup aplikasi: Windows - Memori Virtual Minimum Terlalu Rendah: Sistem Anda kekurangan memori virtual. Windows meningkatkan ukuran file paging memori virtual Anda. Selama proses ini, permintaan memori untuk beberapa aplikasi mungkin ditolak.

Dan kesalahan sebelumnya:

C: disk sudah mencapai atau mendekati kapasitas. Anda mungkin perlu menghapus beberapa file.

Arthur Smirnov
sumber
1

Dalam kasus saya, masalahnya adalah pustaka C ++ / CLI di mana ada panggilan ke NtQuerySystemInformation ; untuk beberapa jenis alasan kadang-kadang (dan dalam keadaan misterius ), ketika itu disebut tumpukan CLR rusak dan aplikasi macet.

Saya telah menyelesaikan masalah menggunakan "tumpukan khusus" yang dibuat dengan HeapCreate dan mengalokasikan buffer yang digunakan oleh fungsi itu di sana.

SiMoStro
sumber
1

Saya tidak yakin ini dapat membantu semua orang, tetapi saya dapat menyiasatinya dengan berlari

devenv.exe /ResetSettings 

... di jalan {Visual_Studio_root}\Common7\Ide

Saya mengalami kesalahan berikut di event log dan VS baru saja mogok dan memulai ulang sepanjang waktu:

Faulting application name: devenv.exe, version: 14.0.25123.0, time stamp: 0x56f22f32
Faulting module name: clr.dll, version: 4.7.2115.0, time stamp: 0x59af88f2
Exception code: 0xc0000005
Fault offset: 0x0015f90e
Faulting process id: 0x3a7c
Faulting application start time: 0x01d353463eaf0c36
Faulting application path: C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\devenv.exe
Faulting module path: C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
Report Id: a232f984-6e80-4f61-9003-e18a035c8f93
Faulting package full name: 
Faulting package-relative application ID: 
Ritesh Varyani
sumber
Ini berhasil juga untuk saya. Konteks: Saya telah mengubah solusi berukuran sedang (~ 25 proyek) ke .NET Core SDK, yang digawangi oleh Proyek Aplikasi Web yang hampir kosong yang menggantikan WAP lama sebelum konversi. Rupanya beberapa pengaturan yang tersisa berbenturan dengan ekspektasi IISExpress dalam proyek baru.
Tomas Aschan
1

Dalam kasus saya, masalahnya adalah karena pengalihan pengikatan duplikat di web.config saya. Info selengkapnya di sini .

Saya berasumsi itu karena NuGet memodifikasi pengalihan pengikatan, tetapi misalnya terlihat seperti ini:

  <dependentAssembly>
    <assemblyIdentity name="Lucene.Net" publicKeyToken="85089178b9ac3181"/>
    <bindingRedirect oldVersion="0.0.0.0-2.9.4.0" newVersion="3.0.3.0"/>
  </dependentAssembly>
  <dependentAssembly>
    <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed"/>
    <bindingRedirect oldVersion="0.0.0.0-11.0.0.0" newVersion="11.0.0.0"/>
  </dependentAssembly>
  <dependentAssembly>
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
    <bindingRedirect oldVersion="0.0.0.0-4.2.0.0" newVersion="4.0.0.0"/>
  </dependentAssembly>
  <dependentAssembly>
    <assemblyIdentity name="Lucene.Net" publicKeyToken="85089178b9ac3181"/>
    <bindingRedirect oldVersion="0.0.0.0-2.9.4.0" newVersion="3.0.3.0"/>
  </dependentAssembly>
  <dependentAssembly>
    <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed"/>
    <bindingRedirect oldVersion="0.0.0.0-11.0.0.0" newVersion="11.0.0.0"/>
  </dependentAssembly>
  <dependentAssembly>
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
    <bindingRedirect oldVersion="0.0.0.0-4.2.0.0" newVersion="4.0.0.0"/>
  </dependentAssembly>

Menghapus semua duplikat menyelesaikan masalah.

Mark Gibbons
sumber
0

Dalam kasus saya, kesalahan ini terjadi saat masuk ke aplikasi SAP Business One 9.1. Dalam acara Windows saya juga dapat menemukan acara kesalahan lain selain yang dilaporkan oleh OP:

Nome dell'applicazione che ha generato l'errore: SAP Business One.exe, versione: 9.10.160.0, timestamp: 0x551ad316
Nome del modulo che ha generato l'errore: clr.dll, versione: 4.0.30319.34014, timestamp: 0x52e0b784
Codice eccezione: 0xc0000005
Offset errore 0x00029f55
ID processo che ha generato l'errore: 0x1d7c
Ora di avvio dell'applicazione che ha generato l'errore: 0x01d0e6f4fa626e78
Percorso dell'applicazione che ha generato l'errore: C:\Program Files (x86)\SAP\SAP Business One\SAP Business One.exe
Percorso del modulo che ha generato l'errore: C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
ID segnalazione: 3fd8e0e7-52e8-11e5-827f-74d435a9d02c
Nome completo pacchetto che ha generato l'errore: 
ID applicazione relativo al pacchetto che ha generato l'errore: 

Mesin menjalankan Windows 8.1, dengan .NET Framework 4.0 diinstal dan tanpa versi 4.5. Seperti yang terlihat dari internet bahwa ini juga bisa menjadi bug di .NET 4, saya mencoba menginstal .NET Framework 4.5.2 dan saya menyelesaikan masalah.

kebiruan
sumber
0

Versi Kerangka Kerja: v4.0.30319 Deskripsi: Proses dihentikan karena pengecualian yang tidak tertangani. Info Pengecualian: System.Reflection.TargetInvocationException

Saya telah menghadapi Kesalahan ini, Aplikasi berfungsi dengan baik pada beberapa PC dan pada beberapa PC yang memberikan kesalahan di atas. Saya menghapus Framework 4.5 dan menginstal ulang ini menyelesaikan masalah saya.

Bersorak.

pengguna4815065
sumber
0

Ini mungkin pengecualian yang terjadi di finalizer. Jika Anda melakukan Pola ~ Class () {Dispose (false); } periksa apa yang Anda buang sebagai sumber daya yang tidak terkelola. Coba saja .. tangkap di sana dan Anda akan baik-baik saja.

Kami menemukan masalah ini karena kami mengalami kegagalan misterius ini tanpa log. Kami melakukan pola yang biasa disarankan menggunakan "Void Dispose (bool disposing)".

Melihat jawaban atas pertanyaan tentang finalis ini, kami menemukan kemungkinan tempat di mana Pembuangan sumber daya yang tidak terkelola dapat menimbulkan pengecualian.

Ternyata di suatu tempat kami tidak membuang objek dengan benar sehingga finalizer mengambil alih diposal sumber daya yang tidak terkelola sehingga terjadi pengecualian.

Dalam hal ini menggunakan Kafka Rest API untuk membersihkan klien dari Kafka. Tampaknya itu melemparkan pengecualian di beberapa titik kemudian masalah ini terjadi.

Nelson J Perez
sumber
0

Saya tidak pernah tahu mengapa ini terjadi pada saya. Itu secara konsisten dapat direproduksi untuk salah satu aplikasi saya, tetapi hilang hanya setelah reboot.

Saya menjalankan Windows 2004 Build 19582.1001 (Insider Preview) dengan .net-4.8 dan saya juga tidak akan terkejut jika hal ini disebabkan oleh sesuatu seperti kesalahan memori perangkat keras. Selain itu, aplikasi saya memuat beberapa kode yang tidak dikelola dan menginisialisasinya, jadi saya tidak dapat membuktikan bahwa kerusakan bukan berasal dari itu.

binki
sumber
-1

Setiap 5-10 menit pool aplikasi saya terus mogok dengan kode keluar ini. Saya tidak ingin merusak kepercayaan Anda kepada Pengumpul Sampah, tetapi solusi berikut berhasil untuk saya.

Saya menambahkan Pekerjaan yang menelepon GC.GetTotalMemory(true)setiap menit.

Saya kira, untuk beberapa alasan, GC tidak secara otomatis memeriksa memori cukup sering untuk sejumlah besar objek sekali pakai yang saya gunakan.

Éric Bergeron
sumber