Bagaimana seharusnya Anda mendiagnosis kesalahan SEHException - Komponen eksternal telah mengeluarkan pengecualian

Setiap kali pengguna melaporkan kesalahan seperti

System.Runtime.InteropServices.SEHException - Komponen eksternal telah membuat pengecualian?

apakah ada yang bisa saya lakukan sebagai programmer untuk menentukan penyebabnya?

Skenario: Satu pengguna (menggunakan program yang ditulis perusahaan saya) telah melaporkan kesalahan ini. Ini mungkin atau mungkin bukan kesalahan satu kali. Mereka menyebutkan bahwa dalam sebulan terakhir, komputer telah dua kali 'berhenti bekerja'. Saya telah belajar dari pengalaman, untuk tidak memahami deskripsi ini terlalu harfiah, karena biasanya berarti seseorang yang berkaitan dengan komputer tidak bekerja seperti yang diharapkan. Mereka tidak dapat memberi saya detail lebih lanjut dan saya tidak dapat menemukan kesalahan yang dicatat. Oleh karena itu, kesalahan ini mungkin saja atau mungkin bukan.

Dari pelacakan tumpukan, kesalahan sebenarnya adalah saat membuat kelas yang tidak secara langsung memanggil kode interop apa pun, tetapi mungkin dipersulit oleh fakta bahwa objek tersebut mungkin merupakan bagian dari daftar yang terikat pada data ke DevExpress Grid.

Kesalahan 'ditangkap' oleh rutinitas pengecualian yang tidak tertangani yang biasanya akan menutup program, tetapi memiliki opsi untuk mengabaikan dan melanjutkan. Jika mereka memilih untuk mengabaikan kesalahan, maka program terus bekerja tetapi kesalahan kembali terjadi saat rutinitas ini dijalankan berikutnya. Namun itu tidak terjadi lagi setelah menutup dan memulai ulang aplikasi kita.

Komputer yang dimaksud tampaknya tidak mengalami stres. Ini menjalankan Vista Business, memiliki memori 2GB dan menurut Task Manager hanya menggunakan sekitar setengah dari itu dengan aplikasi kami hanya sekitar 200Mb.

Ada satu bagian informasi lain yang mungkin relevan atau mungkin tidak relevan. Bagian lain dari program yang sama menggunakan komponen pihak ketiga yang secara efektif merupakan pembungkus dotnet di sekitar dll asli dan komponen ini memang memiliki masalah yang diketahui di mana terkadang, Anda mendapatkan

Mencoba membaca atau menulis memori yang dilindungi. Ini sering menjadi indikasi bahwa memori lain rusak

Pembuat komponen mengatakan bahwa ini telah diperbaiki pada versi terbaru dari komponen mereka yang kami gunakan secara internal, tetapi ini belum diberikan kepada pelanggan.

Mengingat bahwa konsekuensi kesalahan rendah (tidak ada pekerjaan yang hilang dan memulai ulang program dan kembali ke tempat semula paling lama hanya membutuhkan waktu satu menit) dan mengingat bahwa pelanggan akan segera mendapatkan versi baru (dengan pembaruan ketiga- komponen pihak), saya jelas bisa berharap kesalahan tidak akan terjadi lagi.

Tapi adakah yang bisa saya lakukan?

Iya. Kesalahan ini adalah pengecualian terstruktur yang tidak dipetakan ke dalam kesalahan .NET. Mungkin pemetaan DataGrid Anda menampilkan pengecualian asli yang tidak tertangkap.

Anda dapat mengetahui pengecualian apa yang terjadi dengan melihat properti ExternalException.ErrorCode . Saya akan memeriksa pelacakan tumpukan Anda, dan jika itu terkait dengan kisi DevExpress, laporkan masalahnya kepada mereka.

Saya memiliki masalah yang sama dengan SEHException yang muncul saat program saya pertama kali menggunakan pembungkus dll asli. Ternyata DLL asli untuk pembungkus itu tidak ada. Pengecualian sama sekali tidak membantu dalam memecahkan masalah ini. Apa yang membantu pada akhirnya adalah menjalankan procmon di latar belakang dan memeriksa apakah ada kesalahan saat memuat semua DLL yang diperlukan.

jika Anda mengalami masalah seperti yang dijelaskan dalam posting ini:

asp.net mvc debugger melempar SEHException

maka solusinya adalah:

jika Anda memiliki aplikasi apa pun dari Trusteer (seperti hubungan atau apa pun), cukup hapus instalan dan reboot sistem Anda, itu akan berfungsi dengan baik ... temukan solusi ini di sini:

http://forums.asp.net/t/1704958.aspx/8/10?Re+SEHException+thrown+when+I+run+the+application

Pembuat komponen mengatakan bahwa ini telah diperbaiki pada versi terbaru dari komponen mereka yang kami gunakan secara internal, tetapi ini telah diberikan kepada pelanggan.

Tanyakan kepada pembuat komponen bagaimana cara menguji apakah masalah yang didapat pelanggan adalah masalah yang mereka katakan telah mereka perbaiki di versi terbaru mereka, tanpa / sebelum menerapkan versi terbaru mereka ke pelanggan.

Saya telah menemukan kesalahan ini ketika aplikasi berada di jaringan bersama, dan perangkat (laptop, tablet, ...) terputus dari jaringan saat aplikasi sedang digunakan. Dalam kasus saya, itu karena tablet Surface keluar dari jangkauan nirkabel. Tidak ada masalah setelah menginstal WAP yang lebih baik.

Hanya informasi lain ... Mengalami masalah itu hari ini pada sistem Windows 2012 R2 x64 TS di mana aplikasi dimulai dari jalur unc / jaringan. Masalah terjadi pada satu aplikasi untuk semua pengguna server terminal. Menjalankan aplikasi secara lokal bekerja tanpa masalah. Setelah reboot, itu mulai berfungsi lagi - SEHException yang dilemparkan adalah Constructor init dan TargetInvocationException

Konfigurasi mesin saya:

Sistem Operasi: Windows 10 Versi 1703 (x64)

Saya menghadapi kesalahan ini saat men-debug proyek C # .Net saya di edisi Komunitas Visual Studio 2017. Saya memanggil metode asli dengan melakukan p / pemanggilan pada perakitan C ++ yang dimuat saat run-time. Saya mengalami kesalahan yang sama seperti yang dilaporkan oleh OP.

Saya menyadari bahwa Visual Studio diluncurkan dengan akun pengguna yang bukan merupakan administrator pada mesin. Kemudian saya meluncurkan kembali Visual Studio di bawah akun pengguna yang berbeda yang merupakan administrator di mesin. Itu saja. Masalah saya teratasi dan saya tidak menghadapi masalah itu lagi.

Satu hal yang perlu diperhatikan adalah bahwa metode yang dipanggil pada perakitan C ++ seharusnya menulis beberapa hal di registri. Saya tidak melakukan debugging kode C ++ untuk melakukan beberapa RCA tetapi saya melihat kemungkinan bahwa semuanya gagal karena hak administratif diperlukan untuk menulis registri di sistem operasi Windows 10. Jadi sebelumnya ketika Visual Studio berjalan di bawah akun pengguna yang tidak memiliki hak administratif pada mesin, maka panggilan asli gagal.

Saya mendapatkan kesalahan ini saat menjalankan pengujian unit pada cache inmemory yang saya siapkan. Itu membanjiri cache. Setelah membuat cache tidak valid dan memulai ulang VM, itu berfungsi dengan baik.