Crash del driver grafico: diagnosi e fix più efficaci

Crash/timeout del driver: come riconoscerlo senza confonderlo con altro

Un crash/timeout del driver grafico è quando Windows perde temporaneamente il controllo della GPU e poi:

• si riprende (magari chiudendo l’app o “riagganciando” il desktop).
• si blocca (freeze).
• oppure provoca riavvio.

Prima di intervenire, separa questi casi (sono diversi anche come cause):

• Reset “con recupero”: schermo nero/lampeggio per alcuni secondi, l’app si chiude o resta appesa, poi il desktop torna. È uno scenario tipico da reset del driver.
• Freeze senza recupero: immagine ferma (o nera), audio che continua o si interrompe, serve riavviare.
• Riavvio completo: il PC si resetta “di botto” come mancanza di corrente: spesso sembra un driver, ma qui entrano fortemente in gioco alimentazione e stabilità generale.
• Schermo nero senza segnale al boot: se dopo il riavvio non vedi più nulla e il monitor resta “no signal”, non è questo caso → Schermo nero / no signal.

Indizi pratici che ricorrono spesso quando è davvero un timeout driver:

• il problema arriva durante alt-tab, cambio finestra, avvio/chiusura gioco o cambio risoluzione/refresh.
• succede solo con un’app specifica (browser, un gioco, un editor video) e non in altre.
• la sessione “regge” per ore finché non parte un overlay/registrazione/OSD.

Controlli rapidi che aiutano a inquadrare (senza cambiare nulla):

• In Monitoraggio affidabilità trovi spesso un evento all’ora esatta del crash (app bloccata, arresto imprevisto, errori display).
• In Visualizzatore eventi puoi trovare errori legati al display/driver (utile per distinguere reset driver vs crash di sistema).
• Se compare solo quando parte un gioco o un carico pesante, è più coerente trattarlo come instabilità sotto carico.
• Se in Gestione dispositivi compare Code 43, è un caso dedicato → Code 43 in Gestione dispositivi.

Cosa annotare (prima di fare prove)

Basta poco, ma deve essere preciso:

• Windows 10 o 11 e se è iniziato dopo update driver o update Windows.
• Modello GPU e se sono attivi overclock/undervolt o profili di tuning.
• Il crash arriva in idle, in browser/video, o solo in gioco.
• Numero di monitor e tipo di collegamento (HDMI/DP, adattatori, VRR/G-Sync/FreeSync se attivi).
• Nel momento del crash: lampeggio e recupero, freeze, oppure riavvio.
• Se noti un pattern “sempre uguale” (es. sempre al primo alt-tab, sempre entrando in un menù, sempre dopo standby).

Falsi positivi comuni (che portano fuori strada)

• “È colpa del driver” solo perché appare un messaggio: PSU borderline o RAM instabile possono produrre lo stesso effetto.
• Se Windows non vede proprio la GPU (sparita da Gestione dispositivi), non è un semplice timeout → scheda video non rilevata (BIOS/Windows).

Cosa può mandare in timeout il driver grafico su desktop

Le cause più frequenti (quelle che in laboratorio “spiegano” davvero i sintomi) sono:

• Driver in conflitto o residui: installazioni sovrapposte, update falliti, passaggi tra GPU diverse senza pulizia.
• Overlay/OSD/hook: overlay FPS, recorder, OSD di monitoraggio, software RGB o tool che si agganciano alle API grafiche.
• Accelerazione hardware nelle app: browser, player video, Discord e simili possono innescare reset su alcune combinazioni driver/Windows.
• Temperature/hotspot e transitori: non serve arrivare allo spegnimento termico; anche oscillazioni rapide sotto carico possono far emergere instabilità.
• Instabilità RAM/XMP: un profilo XMP/EXPO al limite può manifestarsi come crash GPU (non solo come BSOD).
• OC/UV aggressivi: “stabile sul desktop” non significa stabile in transizioni di carico o con certe API.
• Alimentazione borderline: picchi transitori, cavi non perfetti o connettori non ben innestati possono portare a reset driver o riavvii.

Due edge-case reali (senza inseguire fantasmi):

• crash che compaiono solo con multi-monitor o con un monitor collegato via adattatore: spesso non è la GPU “difettosa”, ma il percorso video (dipende dalla combinazione porta/cavo/adattatore).
• crash che arrivano soprattutto dopo standby/riattivazione: tipicamente è una combinazione tra driver e risparmio energetico.

Cosa provare, in ordine, senza interventi invasivi

Qui l’obiettivo è ridurre variabili e arrivare a un sistema stabile senza interventi invasivi.

1. 1) Riparti da una base pulita e riproducibile

   • Se hai overclock/undervolt attivi, torna temporaneamente a stock: se così sparisce, la direzione è chiara → GPU instabile dopo OC/UV.
   • Disattiva o chiudi overlay/OSD e tool di tuning/monitoring non indispensabili: in molte configurazioni il crash “random” diventa riproducibile solo quando questi sono attivi.
   • Se il problema è soprattutto in browser o app video, prova a disattivare l’accelerazione hardwarenell’app interessata (è una prova diagnostica: se cambia subito comportamento, hai già un indizio forte).

   Dettaglio pratico che torna spesso: se il crash avviene quasi sempre dopo alt-tab, registra l’ora esatta e verifica se coincide con l’avvio/chiusura di overlay o registrazioni in background.

2. 2) Temperature e stabilità sotto carico (quando i crash seguono il “peso” grafico)

   Se i crash arrivano con carico grafico, temperature e comportamento sotto carico fanno parte della diagnosi. Per evitare test casuali, usa criteri ripetibili e confronta il risultato tra una prova e l’altra.

3. 3) Reinstallazione driver “pulita” quando sospetti conflitti

   Se il problema è iniziato dopo update driver, cambio GPU o più reinstallazioni, la pulizia completa è spesso il punto di svolta. Segui la procedura dedicata (evita improvvisazioni) → procedura DDU.

   Dettaglio pratico: se il crash “sparisce” subito dopo una reinstallazione e poi torna al primo aggiornamento/overlay, è un segnale forte di conflitto o componente software che si reinnesta.

4. 4) Quando i crash assomigliano a riavvii o perdita di alimentazione

   Se hai riavvii improvvisi (non solo reset del driver), entra nel territorio alimentazione: verifica con criteri pratici → alimentatore per GPU (watt e margine). Se hai dubbi su connettori/adattatori di alimentazione della GPU o cablaggi non standard, orientati sui controlli corretti → connettori 8 pin / 12VHPWR.

   STOP (criterio chiaro): se i crash peggiorano (freeze più frequenti, riavvii a ripetizione, odore anomalo, connettori caldi), fermati: continuare a tentare “a colpi” aumenta il rischio di danni o corruzione del sistema.

Sintomi diversi, lettura diversa: come interpretarli

Crash con recupero (lampeggio e ritorno al desktop) Molto spesso è un reset driver: overlay, accelerazione hardware e driver “sporchi” sono in cima alla lista.

Freeze totale o riavvio completo Qui pesano molto di più instabilità RAM/XMP, alimentazione e tuning GPU. Se accade solo sotto carico, la lettura più coerente è crash sotto carico GPU.

Crash solo in una singola app/gioco Spesso è un conflitto overlay/API o una specifica impostazione grafica: se il resto è stabile, non partire da soluzioni drastiche. Prima verifica che la correlazione sia reale (stessa scena, stesso punto, stesso pattern).

Crash dopo standby/riattivazione Se è riproducibile soprattutto al resume, è frequente che la reinstallazione pulita e la riduzione di variabili software facciano la differenza (se persiste, torna alla logica di isolamento e non inseguire 10 cause insieme).

Come capire se hai davvero stabilizzato

Considera “risolto” solo quando:

• il crash non si ripresenta per più sessioni (non solo “una volta è andata”).
• in Monitoraggio affidabilità non compaiono nuovi errori display/driver con lo stesso pattern.
• un test mirato resta stabile senza nuovi reset o freeze (criteri in stress test della GPU).

Quando fermarsi e cambiare strategia

Se succede una di queste cose, passa a escalation:

• i crash aumentano di frequenza o diventano riavvii.
• dopo reinstallazione pulita e profilo stock continuano con lo stesso comportamento.
• compaiono segnali di rischio: connettori caldi, odore anomalo, artefatti evidenti prima del crash.

In questi casi evita soluzioni ad alto rischio e passa a diagnosi per esclusione: alimentazione, stabilità generale, e — se possibile — test incrociati hardware tramite laboratorio/assistenza.