Come diagnosticare l'errore SEHException - Il componente esterno ha generato un'eccezione

Ogni volta che un utente segnala un errore come

System.Runtime.InteropServices.SEHException - Il componente esterno ha generato un'eccezione?

c'è qualcosa che io come programmatore posso fare per determinare la causa?

Scenario: un utente (utilizzando un programma scritto dalla mia azienda) ha segnalato questo errore. Questo può o non può essere stato un errore una tantum. Hanno detto che nell'ultimo mese il computer ha "smesso di funzionare" due volte. Ho imparato per esperienza a non prendere questa descrizione troppo alla lettera, poiché di solito significa che qualcuno che si relaziona con il computer non funziona come previsto. Non sono stati in grado di fornirmi ulteriori dettagli e non sono riuscito a trovare alcun errore registrato. Quindi può o non può essere stato questo errore.

Dallo stack-trace, l'errore effettivo si è verificato durante la costruzione di una classe che non chiama direttamente alcun codice di interoperabilità, ma forse complicato dal fatto che l'oggetto può far parte di un elenco associato a un database DevExpress Grid.

L'errore è stato "rilevato" da una routine di eccezione non gestita che normalmente chiuderà il programma, ma ha un'opzione per ignorare e continuare. Se hanno scelto di ignorare l'errore, il programma ha continuato a funzionare ma l'errore si è verificato nuovamente quando è stata eseguita la routine successiva. Tuttavia non si è verificato di nuovo dopo aver chiuso e riavviato la nostra applicazione.

Il computer in questione non sembrava essere stressato. Funziona con Vista Business, ha 2 GB di memoria e, secondo Task Manager, ne utilizzava solo circa la metà con la nostra applicazione, circa 200 Mb.

C'è un'altra informazione che può o non può essere rilevante. Un'altra sezione dello stesso programma utilizza un componente di terze parti che è effettivamente un wrapper dotnet attorno a una dll nativa e questo componente ha un problema noto in cui molto occasionalmente si ottiene un

Tentativo di leggere o scrivere la memoria protetta. Questo è spesso un'indicazione che altra memoria è danneggiata

I produttori di componenti affermano che questo problema è stato risolto nell'ultima versione del loro componente che stiamo utilizzando internamente, ma questo non è stato ancora fornito al cliente.

Dato che le conseguenze dell'errore sono basse (nessun lavoro viene perso e riavviare il programma e tornare dove si trovava richiede solo un minuto al massimo) e dato che il cliente riceverà a breve una nuova versione (con la terza aggiornata- componente del partito), posso ovviamente incrociare le dita e sperare che l'errore non si ripeta.

Ma c'è qualcos'altro che posso fare?

Sì. Questo errore è un'eccezione strutturata che non è stata mappata in un errore .NET. Probabilmente è la tua mappatura DataGrid che genera un'eccezione nativa che non è stata rilevata.

È possibile stabilire quale eccezione si sta verificando esaminando la proprietà ExternalException.ErrorCode . Controllerei la tua traccia dello stack e, se è collegata alla griglia DevExpress, segnala loro il problema.

Ho avuto un problema simile con una SEHException che è stata lanciata quando il mio programma ha utilizzato per la prima volta un wrapper dll nativo. Si è scoperto che mancava la DLL nativa per quel wrapper. L'eccezione non è stata in alcun modo utile per risolvere questo problema. Ciò che ha aiutato alla fine è stato eseguire procmon in background e controllare se c'erano errori durante il caricamento di tutte le DLL necessarie.

se hai un problema come descritto in questo post:

debugger asp.net mvc che lancia SEHException

allora la soluzione è:

se hai qualche applicazione da Trusteer (come rapport o altro) disinstalla e riavvia il tuo sistema, funzionerà bene ... ho trovato questa soluzione qui:

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

I produttori di componenti affermano che questo problema è stato risolto nell'ultima versione del loro componente che stiamo utilizzando internamente, ma questo è stato ancora fornito al cliente.

Chiedere al produttore di componenti come verificare se il problema riscontrato dal cliente è il problema che afferma di aver risolto nella sua ultima versione, senza / prima di distribuire la sua ultima versione al cliente.

Ho riscontrato questo errore quando l'app risiede su una condivisione di rete e il dispositivo (laptop, tablet, ...) viene disconnesso dalla rete mentre l'app è in uso. Nel mio caso, era dovuto a un tablet Surface che usciva dalla portata wireless. Nessun problema dopo l'installazione di un WAP migliore.

Solo un'altra informazione ... Ho avuto quel problema oggi su un sistema Windows 2012 R2 x64 TS in cui l'applicazione è stata avviata da un percorso unc / network. Il problema si è verificato per un'applicazione per tutti gli utenti di Terminal Server. L'esecuzione dell'applicazione in locale ha funzionato senza problemi. Dopo un riavvio ha ricominciato a funzionare: la SEHException generata era stata Constructor init e TargetInvocationException

Le mie configurazioni della macchina:

Sistema operativo: Windows 10 versione 1703 (x64)

Ho riscontrato questo errore durante il debug del mio progetto C # .Net nell'edizione Community di Visual Studio 2017. Stavo chiamando un metodo nativo eseguendo p / invoke su un assembly C ++ caricato in fase di esecuzione. Ho riscontrato lo stesso errore riportato da OP.

Mi sono reso conto che Visual Studio è stato avviato con un account utente che non era un amministratore sulla macchina. Quindi ho riavviato Visual Studio con un account utente diverso che era un amministratore della macchina. È tutto. Il mio problema è stato risolto e non ho più affrontato il problema.

Una cosa da notare è che il metodo che veniva invocato sull'assembly C ++ avrebbe dovuto scrivere poche cose nel registro. Non ho eseguito il debug del codice C ++ per eseguire un po 'di RCA, ma vedo la possibilità che l'intera operazione non funzioni poiché sono necessari privilegi amministrativi per scrivere il registro nel sistema operativo Windows 10. Quindi, in precedenza, quando Visual Studio era in esecuzione con un account utente che non disponeva di privilegi amministrativi sulla macchina, le chiamate native non riuscivano.

Ho ricevuto questo errore durante l'esecuzione di unit test sulla memorizzazione nella cache che stavo configurando. Ha allagato la cache. Dopo aver invalidato la cache e riavviato la VM, ha funzionato bene.