Newsgroup: it.comp.hardware
Titolo: BSOD ripeturi

 
Ultimamente mi è capitato di incorrere in vari BSOD di w10, questo è stato il
primo:
 
https://i.postimg.cc/W1S5M7PV/IMG-20200927-133535.png
 
 
poi molti altri, tutti con cause differenti (vedi sotto il rep di BlueScreenView
di qualcuno)
 
Ho pensato che potesse essere la RAM, anche se quasi nuova, ma prima il Memory
Test di W10 poi anche un Memtest86 da USB non hanno trovato errori:
 
https://i.postimg.cc/ThMNQCwd/IMG-20201027-162735.png
 
 
Partendo con una distro Lubuntu da pendrive dopo qualche ora non ho visto
problemi, ma non so quanto sia affidabile come test perchè il BSOD può avvenire
dopo 5 minuti o dopo 8 ore.
 
Ho anche ripristinato vecchie immagini del s.o. aggiornando anche i drivers
video ma dopo un po' inevitabilmente quanto casualmente compare un BSOD.
 
Questo mi farebbe pensare più ad un problema software che hardware.
 
Oramai non resta altro che reinstallare W10 daccapo, ma sarebbe l'ultima cosa
che voglio perchè nel tempo ho fatto parecchie personalizzazioni che avrei
difficoltà a replicare per intero e ci perderei molto tempo.
 
Consigli?
 
ciao
  Stefano
 
 
==================================================
Dump File         : 102620-7937-01.dmp
Crash Time        : 26/10/2020 18:49:19
Bug Check String  : MEMORY_MANAGEMENT
Bug Check Code    : 0x0000001a
Parameter 1       : 00000000`00041201
Parameter 2       : ffff90bf`feff91a8
Parameter 3       : 03000004`0d381005
Parameter 4       : ffffbb8a`58189250
Caused By Driver  : ntoskrnl.exe
Caused By Address : ntoskrnl.exe+1b73b0
File Description  : NT Kernel & System
Product Name      : Microsoft® Windows® Operating System
Company           : Microsoft Corporation
File Version      : 
Processor         : x64
Crash Address     : ntoskrnl.exe+1b73b0
Stack Address 1   : 
Stack Address 2   : 
Stack Address 3   : 
Computer Name     : 
Full Path         : C:\WINDOWS\Minidump\102620-7937-01.dmp
Processors Count  : 8
Major Version     : 15
Minor Version     : 17763
Dump File Size    : 853.668
Dump File Time    : 26/10/2020 18:50:34
==================================================
 
==================================================
Dump File         : 102720-8750-01.dmp
Crash Time        : 27/10/2020 13:25:02
Bug Check String  : SYSTEM_SERVICE_EXCEPTION
Bug Check Code    : 0x0000003b
Parameter 1       : 00000000`c0000005
Parameter 2       : ffffa20d`ecda75c5
Parameter 3       : ffffd089`f1599de0
Parameter 4       : 00000000`00000000
Caused By Driver  : win32kbase.sys
Caused By Address : win32kbase.sys+175c5
File Description  : Driver kernel Win32k di base
Product Name      : Sistema operativo Microsoft® Windows®
Company           : Microsoft Corporation
File Version      :
Processor         : x64
Crash Address     : ntoskrnl.exe+1b73b0
Stack Address 1   : 
Stack Address 2   : 
Stack Address 3   : 
Computer Name     : 
Full Path         : C:\WINDOWS\Minidump\102720-8750-01.dmp
Processors Count  : 8
Major Version     : 15
Minor Version     : 17763
Dump File Size    : 861.036
Dump File Time    : 27/10/2020 13:26:28
==================================================
 
==================================================
Dump File         : 102620-7937-01.dmp
Crash Time        : 26/10/2020 18:49:19
Bug Check String  : MEMORY_MANAGEMENT
Bug Check Code    : 0x0000001a
Parameter 1       : 00000000`00041201
Parameter 2       : ffff90bf`feff91a8
Parameter 3       : 03000004`0d381005
Parameter 4       : ffffbb8a`58189250
Caused By Driver  : ntoskrnl.exe
Caused By Address : ntoskrnl.exe+1b73b0
File Description  : NT Kernel & System
Product Name      : Microsoft® Windows® Operating System
Company           : Microsoft Corporation
File Version      : 
Processor         : x64
Crash Address     : ntoskrnl.exe+1b73b0
Stack Address 1   : 
Stack Address 2   : 
Stack Address 3   : 
Computer Name     : 
Full Path         : C:\WINDOWS\Minidump\102620-7937-01.dmp
Processors Count  : 8
Major Version     : 15
Minor Version     : 17763
Dump File Size    : 853.668
Dump File Time    : 26/10/2020 18:50:34
==================================================
 
==================================================
Dump File         : 102420-6906-01.dmp
Crash Time        : 24/10/2020 14:27:54
Bug Check String  : SYSTEM_SERVICE_EXCEPTION
Bug Check Code    : 0x0000003b
Parameter 1       : 00000000`c0000005
Parameter 2       : ffffad8f`ef645b3e
Parameter 3       : fffff509`cdebbd80
Parameter 4       : 00000000`00000000
Caused By Driver  : win32kfull.sys
Caused By Address : win32kfull.sys+45b3e
File Description  : Full/Desktop Win32k Kernel Driver
Product Name      : Microsoft® Windows® Operating System
Company           : Microsoft Corporation
File Version      : 
Processor         : x64
Crash Address     : ntoskrnl.exe+1b73b0
Stack Address 1   : 
Stack Address 2   : 
Stack Address 3   : 
Computer Name     : 
Full Path         : C:\WINDOWS\Minidump\102420-6906-01.dmp
Processors Count  : 8
Major Version     : 15
Minor Version     : 17763
Dump File Size    : 908.132
Dump File Time    : 24/10/2020 14:29:12
==================================================
 
 


 
Le temperature sono nella norma? Controlla anche lo storage...infine
se per caso sei sotto overclock riporta tutto a default e
vedi se cosi' le BSOD spariscono.

Controlla anche lo storage...
 
Sapevo che facevo bene a chiedere suggerimenti qui.
 
Dopo il tuo spunto ho preso un SSD SATA da un altro pc e ho ripristinato lì
l'immagine del so,  è da stamane che funziona perfettamente senza nessun BSOD,
tanto che mi fido a scrivere questo messaggio dal pc che dava casini, quello di
ieri sera l'avevo scritto da un portatile per paura di non riuscire a finirlo.
 
Ho anche fatto un'ulteriore prova facendo partire una vm  VirtualBox con il
files .vhd sull' M2, dopo meno di 10 minuti è crashata la vm Xp, ma non
VirtualBox o il so. 
 
Quindi con ogni probabilità il problema è dato dall' SSD Intel M2 NvME tipo 
SSDPEKNW512G8X1 che Intel garantisce 5 anni e invece è durato solo 5 mesi.
 
https://ark.intel.com/content/www/us/en/ark/products/149405/intel-ssd-660p-series-512gb-m-2-80mm-pcie-3-0-x4-3d2-qlc.html
 
 
tra l'altro CrystalDiskInfo non segnala errori o problemi SMART in 820 ore di
lavoro.
 
Non ho dato troppa importanza al fatto che fosse un QLC, invece...
 
Il prossimo sarà almeno un TLC, parlano bene dei Sabrent, il 2280 dovrebbe andar
bene, e non costa molto:
 
https://www.amazon.it/Sabrent-Interno-Rocket-Prestazioni-SB-ROCKET-512/dp/B07KGMBCKD/ref=sr_1_3?_encoding=UTF8
 
 
Aspetto le 16 per inviare il messaggio dopo 8 ore di funzionamento senza BSOD,
facendo gesti scaramantici mentre lo scrivo.
 
Grazie molte,
 
-- 
ciao
  Stefano

 Grazie molte,
 
Figurati!

 MLC
 
Esistono ancora? Non è una legenda allora :-)
 
 
 
-- 
Ciao, Guglielmo.

 E questa direi e' stata la prova del 9... :-)
 
Solo a me non convince la cosa?
 
 

Bender Piegatore Rodriguez ha usato la sua tastiera per scrivere :

Mi pare che la causa sia stata trovata...che poi l'SSD sia
realmente fottuto lato hardware sarebbe da verificare magari
con piu' calma, tipo provare ad eseguire un Secure Erase.

Guglielmo ha spiegato il 28/10/2020 :

Ormai sono in via di estinzione...a parte il Samsung 970Pro
e pochi altri.

Va ancora tutto bene? ;-)
 
Si, ieri è andato tutto il giorno dalle 8 alle 18 senza dare problemi, nella
situazione precedente avrebbe dato diversi BSOD.
 
 Oggi sono stato in giro e l'ho acceso solo ora e funzia. 
 
 
-- 
ciao
  Stefano

 ha scritto:

Solo a me sembra un po' criptica la tua affermazione?
 
-- 
ciao
  Stefano

 ha
scritto:

Mah, adesso sto cercando di sostituirlo in garanzia.
 
-- 
ciao
  Stefano

  Oggi sono stato in giro e l'ho acceso solo ora e funzia. 
 
Ottimo!

 
 
 
Se ti riesce come i due che ho montato io, taglio 512GB, non te ne pentirai.
 
No ci metto al mano sul fuoco perché Sabrent non è un vero produttore, 
ma rimarchia SSD realizzati da altri. E come capita in questi casi, non 
è impossibile che qualche lotto di produzione cambi i componenti montati 
non mantenendo gli stessi standard qualitativi. Inoltre il software di 
gestione fornito da Sabrent non è proprio dei migliori, e non ho trovato 
alcun aggiornamento del firmware. Generalmente dopo aver acquistato un 
Samsung o un Crucial dopo poco qualche aggiornamento mi veniva segnalato 
dal software di gestione.
 
 
In ogni caso il sentire comune è che sono degli ottimi SSD 
dall'invidiabile rapporto qualità/prezzo, e già questa è una bella cosa :)
 
Per dire, se oggi dovessi acquistare nuovi SSD NVMe, ordinerei un altro 
Sabrent di quella linea.
 
 
 

Sabrent di quella linea.
 
Sono contento di sentirlo, da lunedì potrò anche verificarlo.
 
 
-- 
ciao
  Stefano

 rimarchia SSD realizzati da altri. 
 
Se per quello solo Samsung (forse) si fa tutto in casa... :-)

 controller.
 
In reatà l'aggiornamento dei firmware degli SSD è importante perché vengono
risolti bug ed introdotte funzionalità che preservano la durata ed
aumentano le prestazioni. Due esempi:
 
https://www.tomshw.it/hardware/nuovo-firmware-anti-bug-per-ssd-840-evo-inizia-la-distribuzione/
 
https://edge9.hwupgrade.it/news/device/hpe-alcuni-ssd-si-bloccano-esattamente-dopo-40000-ore-per-un-bug-firmware-ecco-come-evitarlo_88067.html
 
 
Se posso essere d'accordo che la sindrome dell'aggiornite acuta che
colpisce molte persone è esagerata, non ne sono affetto per fortuna :-),
sono più per il squadra vincente non si cambia, nel caso degli SSD sono
convinto che invece ha la sua importanza e cerco di tenere aggiornato il
loro firmware.  
 
 
 
-- 
Ciao, Guglielmo.


https://edge9.hwupgrade.it/news/device/hpe-alcuni-ssd-si-bloccano-esattamente-dopo-40000-ore-per-un-bug-firmware-ecco-come-evitarlo_88067.html
 
 
L'esempio del controller che si blocca dopo 40.000 ore è proprio il sintomo di
un prodotto non sufficientemente testato, magari per esigenze di un
time-to-market molto spinto.
 
Tanto se ci sono dei bugs poi si fa un update.
 
Comunque l'andazzo è questo e se ci sono degli aggiornamenti è bene farli.
 
-- 
ciao
  Stefano

 time-to-market molto spinto.
 
40000 ore son 4 anni e mezzo. Mi pare improbabile che qualcuno testi un
dispositivo per cinque anni prima di iniziare a produrlo e venderlo. Rischi
di arrivare sul mercato con due generazioni di ritardo. Prodotto vecchio ed
invendibile.
 
IMHO si tratta del classico bug di programmazione che può capitare per un
errore umano ed un nuovo firmware aggiusta.
 
 
 
-- 
Ciao, Guglielmo.

errore umano ed un nuovo firmware aggiusta.
 
Capita soprattutto se si fanno le cose in fretta e non si testa opportunamente
il tutto, poi naturalmente i bugs nei programmi ci sono sempre stati e sempre ci
saranno.
 
Gli aggiornamenti sono inevitabili, tuttavia mi ricordo di quando nei primi anni
'90 si lavorava con i µController OTP (con prom programmabili una volta sola) e
quanto tempo si perdeva allora a testare un software prima di validarlo,
sicuramente molto piů tempo che a scriverlo e coinvolgendo anche diverse
persone.
 
Poi sono arrivate le flash e il tempo di test č molto diminuito proprio perchč
dopo la scoperta di un bug non dovevi buttare tutti i µC ma potevi aggiornarli e
quindi rimediare dopo.
 
Oggi che il time-to-market č vitale non mi aspetto dei debug profondissimi, ma
in fondo stiamo parlando solo di un controller, non mi ricordo che i controller
degli HDD si aggiornassero, sono davvero tanto piů complessi quelli degli SSD?
 
 
 
-- 
ciao
  Stefano

 controller degli HDD si aggiornassero,
 
Normalmente no ma comunque ci sono stati casi in cui
era raccomandabile aggiornare il firmware causa gravi
bug...tipo all'epoca dei Seagate 7200.1

Dopo dura riflessione, Lorenz ha scritto :

7200.11...m'ero scordato un 1 :-)

 ha
scritto:

Ok, ci sta, i bug ci sono, non siamo in un mondo perfetto.
 
La discussione è nata dal fatto che Guglielmo trovasse una mancanza il fatto che
i Sabrent non avessero degli aggiornamenti, e io gli ho fatto notare che
potrebbe invece essere segno di un prodotto ben testato.
 
Poi ovviamente mettere a punto un software per SSD è una cosa molto complessa e
qualche bug ci sarà sempre, ma per come la vedo io il bug molto spesso è frutto
di un testing non approfondito per ragioni di time-to -market e dal fatto che
tanto mal che vada poi si fa un update.
 
Quindi se non ci sono degli aggiornamenti non è necessariamente un male,
ovviamente imho.
 
Poi con l'ansia odierna di aggionamenti che ci creano sistemi operativi come
Android dove le app si aggiornano continuamente questo può sembrare un difetto,
ma il problema è soprattutto questa mentalità, ancora ovviamente imho.
 
 
-- 
ciao
  Stefano

 ovviamente imho.
 
Si, diciamo che se saltasse fuori pure qui un bug piu'
o meno grave sicuramente provvederebbero a buttare fuori
un firmware correttivo...e questa e' la cosa piu' importante
direi.

direi.
 
Certo, ci mancherebbe, rimediare ai bug fa parte della gestione del prodotto.
 
Ma, vivaddio,  nella mia visione utopistica del mondo, l'aggiornamento dovrebbe
essere un'eccezione, non la regola.
 
 
-- 
ciao
  Stefano

 Oggi sono stato in giro e l'ho acceso solo ora e funzia. 
 
Il fatto è che il giorno dopo l'ho avviato senza ricordarmi di premere F11 e
quindi è partito dall'Intel e nonostante questo non ha più dato nessun BSOD, me
ne sono accordo solo verso sera aprendo Partition Magic.
 
Ripensandoci, poi mi sono ricordato che quando ho aperto il case per inserire
l'SSD da 2" ½ ho notato che le ram erano sulla coppia di slot più lontana dalla
cpu (2-4) mentre il manuale mostrava l'uso della coppia più vicina (1-3).
 
Solo che lo slot più vicono era coperto da una sporgenza della ventola con su
scritto AMD, così ho deciso di invertire la ventola di 180°.
Allora ho staccato il dissipatore, accorgendomi anche che la pasta al silicone
era colata e aveva sporcato il lato della CPUe il lato del socket.
 
Quindi ho tolto il Ryzen 5 dal socket, ho pulito cpu e esterno dello zoccolo e
ho rimontato il tutto, mettendo anche le ram nella coppia 1-3.
 
Da quel momento i BSOD sono scomparsi.
 
Molto probabilmente facendo quelle operazioni ho in qualche modo risolto il
problema, forse era un falso contatto sulle ram o sulla CPU.
 
Comunque l'importante è aver risolto il problema, l' SSD Intel vedrò di metterlo
su un portatile con socket Nvme o al limite in un box esterno USB 3.1.
 
 
-- 
ciao
  Stefano

 Però probabilmente il povero Intel è stato accusato ingiustamente.
 
Ma non mi dire!
Che strano, vero? :)
 
 
 

 problema, forse era un falso contatto sulle ram o sulla CPU.
 
Puo' essere anche se il test che avevi fatto con la VM sembrava
propendere per un problema all'ssd...bah, meglio cosi'. :-)

Che strano, vero? :)
 
Perchè è strano?
 
Con problemi del genere bisogna andare per tentativi e a volte ci si prende per
caso, poi se per te era probabile che fosse un falso contatto di ram o cpu
potevi anche dirlo, avrei seguito tutti i suggerimenti.
 
Fare filosofia dopo è facile.
 
 
-- 
ciao
  Stefano

propendere per un problema all'ssd...bah, meglio cosi'. :-)
 
Beh, i BSOD li faceva in modo del tutto casuale, qualche volta mi è sembrato
pure di vedere qualcosa come se gli schermi si spegnessero per una frazione di
secondo, e il crash della vm è avvenuto in una situazione del genere.
 
Il fatto poi di aver dovuto ripristinare il .vhd da un backup mi ha fatto
pensare erroneamente che fosse un difetto dell'Intel, mentre lui non c'entrava,
anche se era il sospettato principale.
 
 
-- 
ciao
  Stefano

 Fare filosofia dopo è facile.
 
Infatti l'ho detto prima.
E' ORA che tu stai facendo filosofia su qualcosa che ti era stato detto.