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


88

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?

Jawaban:


28

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.


1
StackTrace tidak menyebutkan DevExpress di mana pun, tetapi hanya kelas saya. Akan harus memeriksa untuk melihat apa itu ErrorCode.
sgmoore

Dalam hal ini, coba cari tahu apa sebenarnya yang melontarkan pesan kesalahan tersebut.
Reed Copsey

4
"dengan melihat properti ExternalException.ErrorCode" - apakah Anda memiliki petunjuk tentang bagaimana tepatnya melakukan itu? VS menunjukkan kepada saya "Pengecualian yang tidak tertangani dari jenis 'System.Runtime.InteropServices.SEHException' terjadi di .... dll Informasi tambahan: Eine externe Komponente hat eine Ausnahme ausgelöst.", Tetapi selain di misalnya aplikasi C #, tidak ada tautan untuk melihat "Detail" dari objek pengecualian di mana saja.
ATAU Mapper

Debugger VSCode menampilkan instance $ exception di bawah Locals - ini termasuk bidang Pesan, yang menyertakan kode dan pesan kesalahan yang dapat dibaca manusia.
nightblade9

8

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.



3

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.


1

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.


1
Saya mendapatkannya secara acak saat mengakses berbagai jenis refleksi (GetAssemblyName, GetProperty, Activator, dll.) Baik di kode saya dan pustaka pihak ketiga, dan hanya di satu lingkungan pelanggan, serupa dengan pustaka di lokasi terpencil. Banyak bukti itu bug .net framework.
Andriy K

Andriy K: Saya tidak berpikir ini adalah masalah NET, saya pikir file yang dibuka di jaringan berbagi hilang \ jatuh entah bagaimana, mungkin bug di Windows atau masalah jaringan. Assemblies adalah memori yang dipetakan dan akan ditampilkan dari disk sesuai permintaan (bom waktu), mungkin memori tersebut juga dapat dibuang dalam situasi memori rendah. Jika pegangan file yang dibuka tidak stabil, ini mungkin meledak menjadi asap. .NET mungkin bisa menanganinya dan membuka kembali file (mengatasi masalah), tetapi ini mungkin rumit.
osexpert

Saya memiliki masalah yang sama. Saya mendapatkan System.Runtime.InteropServices.SEHException (0x80004005) tanpa pelacakan tumpukan. Ini adalah InnerException dari TargetInvocationException. TargetInvocationException memang memiliki pelacakan tumpukan, tetapi tidak masuk akal bagi saya karena tampaknya berasal dari main atau Application.Run. Itu terjadi sangat acak, kebanyakan pada malam hari \ malam. Saya kira satu-satunya "solusi" adalah tidak dijalankan dari drive jaringan: - | Mungkin saya menambahkan tanda centang yang dapat memblokir skenario ini: stackoverflow.com/questions/8633680/…
osexpert

0

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


0

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.


0

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.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.