Annullamento delle modifiche apportate al computer in corso su Windows 11: perché e come risolvere

Quando durante un aggiornamento o un upgrade a Windows 11 compare la schermata “Annullamento delle modifiche apportate al computer in corso…”, il sistema sta eseguendo un rollback controllato verso uno stato precedente stabile. Ciò può ad esempio prevedere anche il ripristino di Windows 10. Non si tratta di un semplice errore generico, ma del risultato di un meccanismo di protezione integrato nel motore di installazione di Windows (Windows Setup).

Il comportamento lamentato ciclicamente da molti utenti merita un’analisi tecnica approfondita, perché dietro a quella schermata si nasconde un processo complesso che coinvolge compatibilità hardware, gestione dei driver, integrità del file system e gestione delle varie fasi del processo di installazione.

Architettura degli aggiornamenti di Windows 11: perché esiste il rollback

L’installazione di Windows 11 non è un’operazione che si svolge in un’unica “passata”. È suddivisa in più fasi ben distinte:

• Downlevel phase: avvio da sistema esistente.
• SafeOS phase: ambiente minimale WinPE.
• First Boot: prima configurazione del nuovo sistema.
• Second Boot: completamento e migrazione dati.

Il rollback o ripristino può essere eventualmente innescato in qualsiasi punto critico. Quando ciò accade, Windows utilizza snapshot temporanei e backup della configurazione precedente per ripristinare Windows 10 o lo stato precedente senza perdita di informazioni (almeno nella maggior parte dei casi).

Le cause reali: perché l’upgrade da Windows 10 a Windows 11 può fallire

Quando si passa da Windows 10 a Windows 11, il nodo più critico non è quasi mai l’hardware in senso stretto, ma la continuità del modello driver tra i due sistemi.

Durante un aggiornamento in-place, Windows non reinstalla da zero l’ambiente, ma tenta di migrare integralmente driver, servizi e componenti kernel-mode già presenti. L’approccio, utile per preservare configurazioni e periferiche, introduce però elementi di fragilità: alcuni driver installati in Windows 10, pur funzionando correttamente in quel sistema operativo, possono non rispettare i requisiti più stringenti imposti da Windows 11, soprattutto in termini di sicurezza, firma digitale e integrazione con le nuove policy del kernel.

Il problema può presentarsi durante la fase SafeOS, quando il sistema prova a caricare un set minimo di driver in un ambiente controllato: se anche uno solo di questi – tipicamente storage controller, driver ACPI, GPU legacy o componenti di rete OEM – restituisce comportamenti anomali, incompatibilità o timeout, l’installer non ha margine di recupero e attiva il rollback.

L’aggiornamento può fallire non perché “manca un driver”, ma perché un driver esistente non è più considerato affidabile nel nuovo contesto operativo, e Windows preferisce annullare l’installazione piuttosto che rischiare un sistema non avviabile o instabile.

Già disconnettere periferiche USB non essenziali e dispositivi legacy riduce drasticamente i problemi durante la fase SafeOS.

Diagnosi tecnica: come risalire alla causa

Individuare con precisione perché compare il messaggio “Annullamento delle modifiche apportate al computer in corso…” richiede lo svolgimento di un’analisi attenta. L’interfaccia grafica non fornisce informazioni utili, mentre la causa è sempre tracciata nei log generati durante il processo di upgrade verso Windows 11.

Il punto fondamentale è comprendere che Windows registra ogni fase dell’installazione con un livello di dettaglio molto elevato: non solo l’errore finale, ma anche il contesto, il componente coinvolto e la fase in cui si è verificato il problema.

Dopo un rollback, i file più importanti sono conservati nella cartella temporanea creata durante l’upgrade. È quindi importante verificare il contenuto delle seguenti locazioni di memoria:

C:\$WINDOWS.~BT\Sources\Panther

C:\$WINDOWS.~BT\Sources\Rollback

Si tratta delle cartelle che contengono la cronologia completa delle operazioni effettuate dal motore di setup. In particolare:

setuperr.log: contiene esclusivamente gli errori critici.

setupact.log: include l’intero flusso operativo.

BlueBox.log: registra i controlli di compatibilità.

CompatData*.xml descrive in dettaglio hardware, driver e blocchi rilevati.

La differenza tra questi file è sostanziale: il primo indica cosa è fallito, gli altri spiegano perché.

Come visualizzare la cartella nascosta $WINDOWS.~BT

La cartella $WINDOWS.~BT è nascosta, quindi non è visibile normalmente in Esplora File.

Per accedervi, in Windows 10, si può aprire Esplora file, cliccare su Mostra/Nascondi quindi spuntare la casella Elementi nascosti. Da Windows 11 si può cliccare su Visualizza, Mostra, Elementi nascosti. A questo punto, nella radice del disco C: comparirà la cartella $WINDOWS.~BT.

In alternativa, è possibile accedere direttamente alla cartella premendo Windows+R quindi digitando C:\$WINDOWS.~BT nel campo Apri.

Interpretare i log: dalla lettura alla diagnosi

Un’analisi efficace non consiste nel leggere tutto il log (spesso enorme), ma nel correlare errore, fase e componente coinvolto. Un metodo affidabile prevede quanto segue:

• Partire da setuperr.log per individuare codici errore (es. 0xC1900101) e messaggi di fallimento espliciti.
• Cercare lo stesso timestamp in setupact.log.
• Risalire agli eventi immediatamente precedenti al crash.

Questa correlazione consente di identificare il driver o il servizio coinvolto; la fase dell’upgrade (SafeOS, First Boot,…); eventuali tentativi di recupero già effettuati dal sistema.

Capire quando avviene il rollback è determinante: un blocco nella fase di SafeOS suggerisce problemi quasi sempre legati a driver critici o boot; nella fase First Boot indica errori di inizializzazione dei servizi o della configurazione; Second Boot problemi nella finalizzazione o nella migrazione dati.

Ad esempio, un errore in SafeOS con codice 0xC1900101 indica quasi sempre un driver incompatibile a basso livello, mentre un errore più tardivo può suggerire conflitti software o corruzione del sistema.

Automazione dell’analisi: il ruolo di SetupDiag

Microsoft ha sviluppato uno strumento chiamato SetupDiag che aiuta a trasformare una massa di log tecnici in una diagnosi comprensibile e utilizzabile.

SetupDiag analizza i file di log generati da Windows Setup e li confronta con un database di problematiche note, contenuto in un set di regole aggiornato periodicamente (rules.xml). È così possibile identificare automaticamente pattern ricorrenti – ad esempio specifiche combinazioni di errori, fasi di installazione e componenti coinvolti – e associarli a una causa probabile già documentata.

Dal punto di vista operativo, il tool Microsoft non richiede installazione, non necessita di configurazioni complesse e può essere eseguito direttamente sul sistema che ha subìto il rollback. Una volta avviato, effettua una scansione delle directory contenenti i log ($WINDOWS.~BT) e produce un output umanamente comprensibile, tipicamente sotto forma di file SetupDiagResults.log.

Il valore reale strumento emerge proprio dalla qualità delle informazioni restituite. Il report di SetupDiag non si limita a segnalare un errore, ma include:

informazioni di contesto sul sistema (versione BIOS/UEFI, build di Windows, data dell’upgrade);

• fase in cui si è verificata l’anomalia;
• codice errore completo (es. 0xC1900101-0x2000C);
• descrizione del problema rilevato;
• eventuale riferimento a documentazione o scenari noti.

In molti casi, questo consente di passare direttamente dalla diagnosi alla soluzione, senza dover interpretare manualmente centinaia o migliaia di righe di log.

Va tuttavia chiarito un punto fondamentale: SetupDiag riconosce schemi già noti. Di conseguenza, la sua efficacia è massima quando il fallimento rientra all’interno di casistiche già documentate (driver incompatibili, errori di boot, problemi di spazio o interruzioni del processo). Nei casi più atipici o borderline, il tool può restituire risultati generici o incompleti, rendendo comunque necessaria un’analisi manuale dei log.

Dalla diagnosi all’azione: come trasformare l’errore in una soluzione concreta

Comprendere perché un aggiornamento verso Windows 11 è fallito rappresenta solo il primo passo. L’ulteriore difficoltà consiste nel tradurre l’informazione tecnica – spesso espressa, come abbiamo visto in precedenza, sotto forma di codice errore o riferimento a una fase specifica dell’installazione – in un intervento correttivo.

Non esiste una procedura valida per ogni scenario, ma esiste un metodo rigoroso: partire sempre dagli elementi oggettivi emersi durante la diagnosi, ovvero il codice errore (ad esempio 0xC1900101), la fase in cui si è verificato il blocco (SafeOS, First Boot) e il componente coinvolto.

Nel caso più frequente, ovvero errori riconducibili ai driver – tipicamente segnalati dalla famiglia 0xC1900101 – il problema riguarda la loro incompatibilità nel nuovo sistema operativo.

L’intervento corretto consiste nell’aggiornare manualmente i driver critici (chipset, grafica, rete) utilizzando versioni ufficiali e recenti, rimuovere temporaneamente eventuali componenti problematici e, se necessario, disinstallare software accessorio fornito dai produttori che installa servizi o driver aggiuntivi a basso livello.

Come osservato in precedenza, anche la presenza di periferiche esterne può incidere: dispositivi USB, adattatori o hardware non essenziale possono introdurre variabili non previste durante la fase SafeOS.

In generale, su hardware non ufficialmente supportato da Windows 11, è bene preferire installazioni pulite del sistema operativo dal momento che l’aggiornamento in-place è intrinsecamente fragile. Un’installazione pulita di Windows 11 elimina residui di configurazione, evita migrazione di driver problematici e aumenta la probabilità di successo.