Link alla notizia: https://www.hwupgrade.it/news/sistemi-operativi/windows-11-24h2-e-schermate-blu-microsoft-blocca-l-aggiornamento-su-alcuni-pc_137492.html

Un nuovo blocco di sicurezza impedisce l'aggiornamento a Windows 11 24H2 sui sistemi che utilizzano il driver sprotect.sys di SenseShield Technology. Il componente, utilizzato per la protezione della crittografia in software di sicurezza e soluzioni aziendali, causa schermate blu.

Click sul link per visualizzare la notizia.

Un motivo tra gli altri per ritardare sempre gli aggiornamenti di sistema... Si finisce per fare i beta tester :muro:

Ma non ci posso credere!.... :doh:

Problema con i driver che causano un BSOD e, come sempre, "HA STATA MICRO$OFT... WINZOZZ..." aspetto l'immancabile "passare a linux"

Se non HA STATA LEI, va a finire che HA STATO IO?? :D :D

Problema con i driver che causano un BSOD e, come sempre, "HA STATA MICRO$OFT... WINZOZZ..." aspetto l'immancabile "passare a linux"
In effetti, se l'interazione tra sistema operativo e driver funzionava fino a prima, e con l'aggiornamento del sistema va in conflitto, significa che l'aggiornamento ha cambiato qualcosa.
Quindi sì, con molta probabilità, è colpa di MS...

Qualcuno l'avrà installato quel software quindi HA STATO IL SISTEMISTA

Un motivo tra gli altri per ritardare sempre gli aggiornamenti di sistema... Si finisce per fare i beta tester :muro:

In realtà sono decenni che gli utenti fanno da beta tester ... non ho mai visto un solo SO della M$ funzionare senza bug al day one.
Vero è che ultimamente, ad ogni aggiornamento, i bug vengono introdotti invece di essere corretti :asd:

Problema con i driver che causano un BSOD e, come sempre, "HA STATA MICRO$OFT... WINZOZZ..." aspetto l'immancabile "passare a linux"

Dove hai difficoltà a capire che se prima girava tutto, ma dopo l'aggiornamento del solo SO qualcosa non funziona, non può che essere colpa del SO? :rolleyes:

Per fortuna che esiste GNU/Linux ;)

So che non sembra dal titolo, ma non è "un'aggiornamento" a non funzionare, ma è la versione 24H2 di cui hanno bloccato l'aggiornamento dei computer che hanno quei driver.
Driver che non è dato sapere quando sono stati rilasciati e per quale sistema operativo.
Immagino che se cercassi su internet non troverei mai dei kernel panic dovuti ad un driver dopo l'aggiornamento del kernel...

L'articolo riporta:
La natura del problema risiede nell'incompatibilità tra il driver sprotect.sys e le modifiche apportate in Windows 11 24H2. Quando il sistema operativo aggiornato tenta di interagire con questo componente, si verificano conflitti che portano al blocco completo del sistema e alla visualizzazione degli errori fatali.

Quindi sono le successive modifiche fatte al SO che creano problemi con il driver sprotect.sys, che prima delle modifiche non dava problemi. Almeno questo è ciò che capisco io.
Senza contare tutti gli altri problemi intrododtti con altri software (come riportato alla fine dell'articolo). Ergo deduco che a dare problemi sono le recenti modifiche di Wondows :doh:

La natura del problema risiede nell'incompatibilità tra il driver sprotect.sys e le modifiche apportate in Windows 11 24H2 rispetto a Windows 11 23H2, non da Windows 11 24H2 con le patch di gennaio rispetto a quelle di marzo.
Un po' come Debian 12.4 rispetto a Debian 12.5 o RHEL 9.4 e RHEL 9.5.

Con Windows 11 Micosoft ha introddo la possibilità di non far effettuare l'aggiornamento a Build successive in caso siano installati componenti che si sà già che causano problemi.
Alcuni problemi sono sorti durante i test, altri, come questo, sono stati identificati mesi dopo perché probabilmente un componente meno diffuso.

La natura del problema risiede nell'incompatibilità tra il driver sprotect.sys e le modifiche apportate in Windows 11 24H2 rispetto a Windows 11 23H2, non da Windows 11 24H2 con le patch di gennaio rispetto a quelle di marzo.
...

Non riesco a seguirti.
Lo scrivi anche tu che il problema risiede nelle modifiche apportate in Windows 11 24H2, quindi modifiche avvenute dopo il rilascio del driver imputato.
Quindi il driver che è stato scritto funziona per un SO (perché probabilmente ne rispetta le caratteristiche/specifiche), mentre crea problemi con la nuova versione dello stesso SO. Della serie, se non è colpa del SO (cioè di chi scrive il SO) di chi è la colpa? Se in corsa d'opera cambi le regole del gioco, la colpa è del giocatore? :doh:
Se poi si riscrivono nuovamente le regole per rientrare in partita, non c'è gioco. :rolleyes:

Non riesco a seguirti.
Lo scrivi anche tu che il problema risiede nelle modifiche apportate in Windows 11 24H2, quindi modifiche avvenute dopo il rilascio del driver imputato.
Quindi il driver che è stato scritto funziona per un SO (perché probabilmente ne rispetta le caratteristiche/specifiche), mentre crea problemi con la nuova versione dello stesso SO. Della serie, se non è colpa del SO (cioè di chi scrive il SO) di chi è la colpa? Se in corsa d'opera cambi le regole del gioco, la colpa è del giocatore? :doh:
Se poi si riscrivono nuovamente le regole per rientrare in partita, non c'è gioco. :rolleyes:

Guarda, (da profano ti dico che) è semplice:
la sequenza degli eventi è quella da te descritta.

Al t0 rilascio il software XY che rispetta le specifiche dell'OS(t0) su cui deve funzionare.

Poi viene il t1, di solito non dal giorno al domani (diciamo a cadenza annuale??).

XY dovrà necessariamente conformarsi a quelle che sono le nuove condizioni (OSt1) pena l'impossibilità di funzionare su quel ramo...oppure MS, nel frattempo (t0→t1) non può operare modifiche al kernel perché gli sviluppatori di XY non hanno aggiornato il driver del loro software? (si ferma cioè lo sviluppo che non è solo "ciò che appare alla massa" ma che nasconde molto altro dietro??)

Q U E S T O VANTAGGIO (https://www.hwupgrade.it/forum/showpost.php?p=48765236&postcount=2), per dire, non è possibile sugli OS < 11 24H2:
ci rinunciamo perché XY, dopo aver rilasciato il suo software, ne ha congelato lo sviluppo?
Il tempo per adeguarlo alle nuove condizioni lo hanno avuto (t0→t1), problemi loro (o HA COLPA LORO) e il mondo va avanti lo stesso..


*giusto, dimenticavo una integrazione cruciale:
certo, il lassismo della software house XY si scarica sulle incolpevoli realtà che registrano BSoD...ma, se la colpa di questo meccanismo va addossata a qualcuno, "NON HA di MS" che ha si! modificato le condizioni informando però l'ecosistema con largo anticipo..e siccome oltretutto sembra di capire che i software che si avvalgono del driver sviluppato da XY siano estremamente di nicchia, si!, ha colpa anche il sistemista come giustamente osservato da destroyer85 per non aver testato adeguatamente il nuovo ambiente col vecchio software..

*insert gif Steve carrell pushing button and saying THANK YOU! *

*insert gif Steve carrell pushing button and saying THANK YOU! *

per farla semplice, altrimenti diversi babbei pensano sia io col doppio utente a darmi manforte:
che vor di'?? :D

C'ho preso (/la pensiamo allo stesso modo) oppure??

https://media3.giphy.com/media/1Z02vuppxP1Pa/giphy.gif?cid=6c09b9524nvihgyp3qtq7vcxa22uravno1rqkfscx1quqs1i&ep=v1_internal_gif_by_id&rid=giphy.gif&ct=g