Newsgroup: it.comp.os.win.windows10
Titolo: SYSTEM_THREAD_EXCEPTION_NOT_HANDLED

 
questa è un'altra cosa che mi da noia
 
SYSTEM_THREAD_EXCEPTION_NOT_HANDLED
 
spesso me lo fa CPUSB.SYS
 
che dovrebeb essere il dirver prodotto dalla micropi per la gestiuone 
delle chiavi hardware
 
anche qusta cosa a legegre il web è diffusa per i più svariati motivi e 
non dipende dal SO o meglio, inizia apaprire da win 8 in avanti
 
ma esattemente cosa accade?

 ma esattemente cosa accade?
 
Programma scritto a pene di segugio. Molto in generale...
si crea un errore in un thread di quel driver (un errore
 qualunque, da un timeout
in un'attesa fino a un errore di rete o di disco). Un programma
 decente rileverebbe l'errore
e lo gestirebbe: o riprova oppure annulla l'azione, o fa qualche
 altra cosa, ma in ogni caso
deve perlomeno avvisare il programma principale che l'errore c'č stato.
In quel caso invece il thread si pianta e non viene presa nessuna
 contromisura; il sistema
operativo se ne accorge, blocca il driver per evitare che faccia
 danni e avvisa l'utente.
Ripeto, spiegazione superficiale, tanto per dare un'idea O:-)
 
Bye, G.
 
 
----Android NewsGroup Reader----
http://usenet.sinaapp.com/
 

> ma esattemente cosa accade?
 
Giusto paperino. Anche la versione di un programma
compilata in modo "release" mantiene un minimo di
controlli interni e se non lo fa il programma lo fa il SO.
 
Quando qualcosa in un programma va storto il programmatore
dovrebbe gestire il problema correggendone la causa. Il
programma in questo caso lancia un'eccezione come si dice
in linguaggio tecnico. Questa può venire catturata dal
flusso del programma e gestita, che so una divisione per
zero e ti compare la finestra dicendo che il valore da te
inserito non può essere zero. Ma se il programmatore non
lo fa, questa eccezione risale lungo tutta la catena delle
chiamate di subroutines fino al programma principale e a
quel punto viene passata al sistema operativoe tu leggi
il messaggio che hai visto. Insomma, mancata gestione di 
una condizione di errore.
 
Sicuramente programmi scritti male fanno questo ma va
detto che programmare in multithreading è estremamente
difficile e qualcosa sfugge sempre. Credo non si possa
fare niente se non attendere una nuova release del
software o avere l'enorme botta di fortuna di identificare
precisamente cosa produce l'errore in modo da evitarlo.
Più o meno come sparare alla cieca sperando di cogliere un
bersaglio assegnato.
 
 
-- 
"Dovrebbe smettere di praticare auto erotismo."
"Diamine, dottore, perché mai?"
"Perché le sto parlando."
 

 programma decente rileverebbe l'errore e lo gestirebbe
 
di norma, viene richiesto che i kernel drivers (e quello sopra è un
kernel driver) gestiscano gli errori, in caso contrario, il kernel
cerca di rimediare come può e, se non riesce... BSOD, per cui concordo
con te sul fatto che si tratti di un driver mal scritto o, molto
probabimente, semplicemente riadattato man mano da versioni precedenti
(in alcuni casi ci sono driver "portati" da NT4, vedi tu :-P !!)
 
Detto questo; qui ci sono ulteriori dettagli sull'errore
 
https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/bug-check-0x7e--system-thread-exception-not-handled
 
 
ulteriori informazioni potrebbero essere presenti nel log eventi di
windows e/o possono essere ricavate usando questo tool
 
https://www.nirsoft.net/utils/blue_screen_view.html
 
 
tornando al problema ed al driver, sembra che si tratti di un problema
abbastanza diffuso, vedi ad esempio
 
https://answers.microsoft.com/en-us/windows/forum/all/systemthreadexceptionnothandled-cpusbsys/ba696c37-866c-4a54-b0fa-96a452e678c6
 
 
e siccome l'azienda che distribuisce quel driver è italiana
 
https://www.micropi.it/chiave-hardware-cpusb
 
 
si potrebbe provare a contattarla fornendo i necessari dettagli; è
possibile che abbiano un driver aggiornato o che possano suggerire un
workaround per evitare il problema
 
 

 difficile
 
non credo sia un problema di multithreading; l'errore potrebbe essere
semplicemente causato da (es.) una mancata allocazione di memoria o dal
mancato controllo di validità di un puntatore; il problema è che una
cosa del genere, in un *kernel* driver (che è un filino diverso da un
pezzo di codice che gira un "user mode") causa spesso BSOD e, come
giustamente ha scritto il Papero, è indice di cattiva programmazione;
probabilmente l'azienda che ha messo insieme il driver, ha preso il
driver generico scritto da chissà chi, e chissà quanti anni fa, e lo ha
semplicemente "riadattato" senza prendersi la briga di controllare a
fondo il codice :P