SEHException hatasını nasıl teşhis etmelisiniz - Harici bileşen bir istisna attı


88

Bir kullanıcı aşağıdaki gibi bir hata bildirdiğinde

System.Runtime.InteropServices.SEHException - Harici bileşen bir istisna mı attı?

Bir programcı olarak nedenini belirlemek için yapabileceğim herhangi bir şey var mı?

Senaryo: Bir kullanıcı (şirketimin yazdığı bir programı kullanarak) bu hatayı bildirdi. Bu bir defaya mahsus bir hata olabilir veya olmayabilir. Geçen ay bilgisayarın iki kez 'çalışmayı durdurduğunu' belirttiler. Deneyimlerimden öğrendim, bu açıklamayı tam anlamıyla almamayı çünkü bu genellikle bilgisayarla ilgili birinin beklendiği gibi çalışmadığı anlamına gelir. Bana daha fazla ayrıntı veremediler ve kaydedilmiş herhangi bir hata bulamadım. Dolayısıyla bu hata olabilir veya olmayabilir.

Yığın izlemeden, gerçek hata, herhangi bir birlikte çalışma kodunu doğrudan çağırmayan, ancak nesnenin bir DevExpress Grid'e bağlı bir listenin parçası olabileceği gerçeğiyle karmaşıklaşan bir sınıf oluştururken meydana geldi.

Hata, normalde programı kapatan ancak yok sayma ve devam etme seçeneğine sahip olan işlenmemiş bir istisna rutini tarafından 'yakalandı'. Hatayı görmezden gelmeyi seçtilerse, program çalışmaya devam etti ancak bu rutin bir sonraki çalıştırmada hata yeniden oluştu. Ancak uygulamamızı kapatıp yeniden başlattıktan sonra tekrar olmadı.

Söz konusu bilgisayar, stresli görünmüyordu. Vista Business çalıştırıyor, 2GB belleğe sahip ve Görev Yöneticisine göre bizim uygulamamızla bunun sadece yaklaşık yarısını yaklaşık 200Mb kullanıyordu.

İlgili olabilecek veya olmayabilecek başka bir bilgi daha var. Aynı programın başka bir bölümü, etkin bir şekilde yerel bir dll etrafında bir dotnet sarmalayıcısı olan bir üçüncü taraf bileşenini kullanır ve bu bileşenin bilinen bir sorunu vardır, çok nadiren bir

Korumalı belleği okumaya veya yazmaya çalıştı. Bu genellikle diğer belleğin bozuk olduğunun bir göstergesidir

Bileşen üreticileri, şirket içinde kullandığımız bileşenlerinin en son sürümünde bunun düzeltildiğini, ancak bunun henüz müşteriye verilmediğini söylüyorlar.

Hatanın sonuçlarının düşük olduğu göz önüne alındığında (hiçbir iş kaybedilmez ve programı yeniden başlatmak ve bulunduğu yere geri dönmek en fazla bir dakika sürer) ve müşterinin kısa süre içinde yeni bir sürüm alacağı (güncellenmiş üçüncü ile birlikte) parti bileşeni), açıkça parmaklarımı çarpabilir ve hatanın bir daha oluşmamasını umabilirim.

Ama yapabileceğim başka bir şey var mı?

Yanıtlar:


28

Evet. Bu hata, .NET hatasıyla eşlenmemiş yapısal bir istisnadır. Muhtemelen DataGrid eşlemeniz yakalanmayan yerel bir istisna atıyor.

ExternalException.ErrorCode özelliğine bakarak hangi istisnanın meydana geldiğini anlayabilirsiniz . Yığın izinizi kontrol ederdim ve DevExpress şebekesine bağlıysa sorunu onlara bildirin.


1
StackTrace hiçbir yerde DevExpress'ten bahsetmedi, sadece benim sınıfımdan. Hata Kodunun ne olduğunu kontrol etmeniz gerekecek.
sgmoore

Bu durumda, hata mesajını tam olarak neyin attığını anlamaya çalışın.
Reed Copsey

4
"ExternalException.ErrorCode özelliğine bakarak" - bunu tam olarak nasıl yapacağınıza dair herhangi bir ipucunuz var mı? VS bana şunu gösteriyor "'System.Runtime.InteropServices.SEHException' türünde işlenmemiş bir istisna oluştu .... dll Ek bilgi: Eine externe Komponente hat eine Ausnahme ausgelöst.", Ancak örneğin C # uygulamaları dışında bağlantı yok herhangi bir yerde istisna nesnesinin "Ayrıntılarına" bakmak için.
OR Mapper

VSCode'un hata ayıklayıcısı, Yereller altında bir $ istisna örneğini gösterir - bu, kodu ve insan tarafından okunabilir bir hata mesajını içeren bir Mesaj alanını içerir.
nightblade9

8

Programım ilk kez yerel bir dll sarmalayıcısı kullandığında ortaya çıkan SEHException ile benzer bir sorun yaşadım. Bu sarmalayıcı için yerel DLL'nin eksik olduğu ortaya çıktı. İstisna, bunu çözmeye hiçbir şekilde yardımcı olmadı. Sonunda yardımcı olan şey, procmon'u arka planda çalıştırmak ve gerekli tüm DLL'leri yüklerken herhangi bir hata olup olmadığını kontrol etmekti.



3

Bileşen üreticileri, şirket içinde kullandığımız bileşenlerinin en son sürümünde bunun düzeltildiğini söylüyorlar, ancak bu henüz müşteriye verildi.

Bileşen üreticisine, müşterinin karşılaştığı sorunun, müşteriye en son sürümünü dağıtmadan / önce en son sürümlerinde düzelttiklerini söyledikleri sorun olup olmadığını nasıl test edeceğini sorun.


1

Uygulama bir ağ paylaşımında bulunduğunda ve uygulama kullanımdayken cihazın (dizüstü bilgisayar, tablet, ...) ağ ile bağlantısı kesildiğinde bu hatayla karşılaştım. Benim durumumda, bir Surface tabletin kablosuz kapsama alanının dışına çıkmasından kaynaklanıyordu. Daha iyi bir WAP kurduktan sonra sorun yok.


1
Hem kodumda hem de üçüncü taraf kitaplıklarında farklı yansıma türlerine (GetAssemblyName, GetProperty, Activator, vb.) Erişirken ve uzak konumdaki kitaplıklarla benzer şekilde yalnızca bir müşteri ortamında rastgele alıyordum. Net çerçeve hatası olduğuna dair birçok kanıt var.
Andriy K

Andriy K: Bunun bir .NET sorunu olduğunu düşünmüyorum, sanırım ağ paylaşımında açılan dosya (lar) kayboldu / bir şekilde düştü, belki Windows'ta bir hata veya ağ sorunu olabilir. Derlemeler bellek eşlenir ve isteğe bağlı olarak diskten (saatli bomba) sayfalanır, muhtemelen bellek düşük bellek durumlarında da atılabilir. Açılan eğe tutamaçları sabit değilse bu muhtemelen dumanla patlar. .NET belki bunu halledip dosyayı yeniden açabilirdi (problemi düzeltin), ancak karmaşık olabilir.
osexpert

Bende de aynı sorun var. Yığın izleme olmadan System.Runtime.InteropServices.SEHException (0x80004005) alıyorum. Bu, TargetInvocationException'ın InnerException'dur. TargetInvocationException yığın izleme özelliğine sahip, ancak ana veya Application.Run'dan geliyormuş gibi göründüğü için bana mantıklı gelmedi. Çoğunlukla akşamları geceleri çok rastgele olur. Sanırım tek "çözüm" ağ sürücüsünden çalıştırılmamaktır: - | Belki bu senaryoyu engelleyebilecek bir çek eklerim: stackoverflow.com/questions/8633680/…
osexpert

0

Sadece başka bir bilgi ... Uygulamanın bir amc / ağ yolundan başlatıldığı bir Windows 2012 R2 x64 TS sisteminde bugün bu sorunu yaşadım. Sorun, tüm terminal sunucusu kullanıcıları için bir uygulamada ortaya çıktı. Uygulamanın yerel olarak yürütülmesi sorunsuz çalıştı. Yeniden başlatmanın ardından tekrar çalışmaya başladı - SEHException'ın atılanları Oluşturucu başlatma ve TargetInvocationException olmuştu


0

Makine yapılandırmalarım:

İşletim Sistemi: Windows 10 Sürüm 1703 (x64)

Visual Studio 2017 Community sürümünde C # .Net projemde hata ayıklarken bu hatayla karşılaştım. Çalışma zamanında yüklenen bir C ++ derlemesinde p / invoke gerçekleştirerek yerel bir yöntemi çağırıyordum. OP tarafından bildirilen aynı hatayla karşılaştım.

Visual Studio'nun makinede yönetici olmayan bir kullanıcı hesabıyla başlatıldığını fark ettim. Daha sonra, makinede yönetici olan farklı bir kullanıcı hesabı altında Visual Studio'yu yeniden başlattım. Bu kadar. Sorunum çözüldü ve sorunla bir daha karşılaşmadım.

Unutulmaması gereken bir şey, C ++ derlemesinde çağrılan yöntemin kayıt defterine birkaç şey yazması gerektiğidir. Bazı RCA yapmak için C ++ kodunda hata ayıklamaya gitmedim, ancak Windows 10 işletim sisteminde kayıt defteri yazmak için yönetici ayrıcalıkları gerektiğinden her şeyin başarısız olma olasılığını görüyorum. Bu nedenle, daha önce Visual Studio, makinede yönetici ayrıcalıklarına sahip olmayan bir kullanıcı hesabı altında çalışırken, yerel çağrılar başarısız oluyordu.


0

Bu hatayı, kurduğum bellek içi önbelleğe alma üzerinde birim testleri çalıştırırken aldım. Önbelleği doldurdu. Önbelleği geçersiz kıldıktan ve sanal makineyi yeniden başlattıktan sonra iyi çalıştı.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.