TL;DR: il caso KB5121003 mostra che un’utility per luci RGB può diventare un problema di infrastruttura. Microsoft collega blocchi, chiusure, errori EXCEPTION_ACCESS_VIOLATION e riavvii improvvisi a componenti con nomi simili a inpoutx64 installati da alcune periferiche. Per una PMI la risposta non è modificare il registro su tutti i PC. Prima si identifica il perimetro, poi si isola il driver, si prova la mitigazione su una macchina, si prepara il rollback e si distribuisce la correzione a gruppi. La regola da portarsi dietro è semplice: ogni utility che installa un driver va gestita come software di sistema, anche se serve soltanto a cambiare colore a una tastiera.

L’aggiornamento Windows dell’11 agosto 2026, KB5121003, è il punto di partenza del caso. Nella pagina ufficiale sullo stato di Windows 11, Microsoft riferisce di giochi che non rispondono, si chiudono senza avviso, mostrano l’errore EXCEPTION_ACCESS_VIOLATION o provocano un riavvio. L’indagine in corso collega il problema a periferiche o componenti interni con illuminazione RGB e a driver o componenti con nomi simili a inpoutx64. Sono indicate come interessate le versioni 24H2 e 25H2 di Windows 11; Windows Server non rientra nel perimetro dichiarato.

La notizia sembra lontana dal lavoro di una piccola azienda perché i titoli citati da Microsoft sono videogiochi. La lezione, però, riguarda qualsiasi postazione Windows: software per mouse, tastiere, dock, cuffie, ventole e schede madri può installare servizi e driver con privilegi molto più ampi della funzione visibile. Il colore è accessorio. Il componente che lo controlla può non esserlo.

Il problema non è l’RGB: è il confine di fiducia

Una normale applicazione gira in user mode e, quando fallisce, di solito si chiude. Un driver opera più vicino al kernel e può portarsi dietro conseguenze diverse. Questo non prova che ogni utility RGB sia vulnerabile o che inpoutx64 sia malware. Microsoft sta ancora indagando sul rapporto preciso tra i componenti RGB e i programmi che attivano il problema. Il dato operativo già sufficiente è un altro: un software considerato cosmetico ha aggiunto una dipendenza capace di compromettere la stabilità della macchina.

Per chi amministra WordPress, hosting, posta o automazioni, un riavvio improvviso non è solo una seccatura. Può interrompere un deploy, corrompere un trasferimento, lasciare una procedura a metà o far perdere le prove utili a capire cosa è successo. Se quella postazione conserva sessioni amministrative e token, ridurre i componenti privilegiati non necessari è anche una misura di riduzione della superficie di rischio. Non serve trasformare il caso in un allarme sicurezza: basta trattarlo per quello che è, un difetto di gestione dell’endpoint.

La mia take è netta: l’inventario software non deve fermarsi alle applicazioni “di lavoro”. Se un installer richiede privilegi amministrativi, aggiunge un servizio o carica un driver, entra nell’infrastruttura. Il nome commerciale e la funzione percepita non cambiano il livello di accesso.

Fase 1: confermare il perimetro prima di correggere

La prima mossa non è disinstallare tutto. È capire quali dispositivi condividono le condizioni del caso. Registra per ogni macchina interessata la versione di Windows, il numero di build, l’aggiornamento installato, le utility di periferica presenti e l’ora dei crash. winver basta per un controllo manuale; in PowerShell puoi raccogliere i dati di sistema senza modificare nulla:

Get-ComputerInfo |
  Select-Object WindowsProductName, WindowsVersion, OsBuildNumber

Poi verifica se il servizio citato da Microsoft esiste. La query seguente è di sola lettura e restituisce un risultato soltanto se Windows conosce quel nome:

Get-CimInstance Win32_SystemDriver -Filter "Name='inpoutx64'" |
  Select-Object Name, State, StartMode, PathName

Non usare la presenza del file come unica diagnosi. Cerca la sequenza completa: aggiornamento installato, utility o periferica coinvolta, evento riproducibile e sintomo coerente. Apri anche Monitoraggio affidabilità con perfmon /rel e confronta l’ora del problema con installazioni, aggiornamenti e arresti inattesi. Nel Visualizzatore eventi conserva almeno gli eventi System e Application intorno al crash. Se Windows ha prodotto un dump, non cancellarlo durante i primi tentativi: Microsoft raccomanda di raccogliere il file e analizzare il driver coinvolto nei casi di stop error.

Questo passaggio evita due errori costosi: attribuire al driver RGB un crash che ha un’altra causa oppure applicare una mitigazione corretta a macchine che non ne hanno bisogno. In una flotta di dieci PC, un foglio con hostname, build, utility, periferica, presenza del servizio e ultimo crash è già sufficiente per vedere il pattern.

Fase 2: contenere senza perdere la possibilità di tornare indietro

Microsoft pubblica un workaround preciso: disabilitare temporaneamente il driver inpoutx64 impostando a 4 il valore Start nella chiave HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\inpoutx64, quindi riavviare. La stessa pagina avverte che la modifica può compromettere le funzioni RGB o il software che le gestisce e chiede di eseguire prima un backup del registro.

Questa non è una modifica da distribuire alla cieca con uno script copiato da un articolo. Applicala soltanto su una macchina che presenta le condizioni verificate nella fase precedente. Prima esporta la chiave, annota il valore originale e prepara l’accesso locale o una procedura di ripristino. Dopo il riavvio controlla tre cose: il sintomo non si ripete, le funzioni essenziali della periferica restano disponibili e non compaiono nuovi errori di driver.

Se il test fallisce, ripristina il valore precedente e raccogli nuove prove. Se funziona, non significa che il caso sia chiuso: significa che hai una mitigazione temporanea da tenere separata dalla correzione definitiva del vendor o di Microsoft. Registra data, operatore e dispositivi modificati, così potrai rimuovere il workaround quando l’indagine sarà risolta.

Per i dispositivi compatibili, Dynamic Lighting di Windows può centralizzare il controllo delle luci tramite lo standard HID LampArray e ridurre il numero di controller proprietari in esecuzione. Non è una sostituzione universale: compatibilità, firmware e funzioni vanno verificati modello per modello. È però un buon criterio di acquisto futuro. A parità di periferica, preferire il controllo nativo evita un altro updater, un altro servizio e un’altra dipendenza da testare.

Fase 3: testare update e driver su un anello pilota

Il caso è emerso dopo un aggiornamento mensile, ma la risposta non dovrebbe essere bloccare gli update a tempo indeterminato. Gli aggiornamenti correggono vulnerabilità e difetti reali; ritardarli senza una data di uscita sostituisce un rischio visibile con uno meno visibile. La soluzione è separare le macchine per fasi.

Per una PMI bastano tre gruppi:

  • un dispositivo pilota rappresentativo, ripristinabile e non usato per attività critiche;
  • un gruppo limitato con hardware e applicazioni diverse;
  • il resto della flotta, comprese le postazioni più delicate.

Microsoft usa lo stesso principio nelle policy Update ring di Intune e raccomanda di pianificare approvazioni e distribuzioni progressive anche per driver e firmware. Non serve Intune per adottare il metodo. Puoi mantenere i tre gruppi in un inventario e applicare le finestre di aggiornamento manualmente. Quello che conta è non scoprire una regressione su tutte le postazioni nello stesso minuto.

Definisci prima la soglia di stop: un riavvio inatteso sul pilota, due errori uguali nel gruppo limitato o la perdita di una funzione critica fermano l’espansione. Il rollback va preparato prima dell’update, non durante l’incidente. Per ogni utility di periferica conserva installer approvato, versione precedente, procedura di rimozione e contatto del vendor.

Il protocollo in quattro fasi

Quando una postazione Windows inizia a bloccarsi dopo un update, questa sequenza tiene separata la diagnosi dalla fretta:

  1. Inventario. Raccogli build, KB, periferiche, utility, driver e orari. Non modificare ancora la macchina.
  2. Correlazione. Confronta Monitoraggio affidabilità, eventi e dump con l’azione che scatena il problema. Cerca una riproduzione controllata.
  3. Mitigazione pilota. Applica il workaround ufficiale su un solo dispositivo, con backup e valore originale documentato.
  4. Rollout e uscita. Estendi a gruppi solo se il test passa; monitora e pianifica la rimozione della mitigazione quando arriva la correzione.

L’automazione può aiutare nelle prime due fasi. Uno script di sola lettura può raccogliere build, servizi e software installato; un modello AI può raggruppare eventi simili o trasformare i log in una timeline. Non dovrebbe decidere da solo una modifica al registro. Il punto in cui il workflow scrive sulla macchina deve avere un criterio verificabile, un approvatore e un rollback.

È lo stesso principio usato per verificare provenienza, firma e rollout dei driver prima di distribuirli. Nel caso RGB il file può essere legittimo e il problema può nascere dall’interazione con un update o un’applicazione. Il gate resta utile: rende visibile quale componente è entrato, su quali PC e con quale versione.

La policy minima per le utility di periferica

Mouse, tastiere e dock arrivano spesso con un invito a installare il software del produttore. In azienda quell’invito dovrebbe passare da una policy breve. Per ogni utility registra proprietario, funzione necessaria, versione, privilegi richiesti, servizi o driver aggiunti e modalità di aggiornamento. Se serve soltanto per impostare una luce una volta, valuta se puoi configurare il dispositivo e poi rimuovere l’applicazione, oppure usare il controllo nativo.

Le domande da fare sono concrete:

  • Questa funzione è necessaria al lavoro o è solo una personalizzazione?
  • L’utility installa un driver, un servizio in avvio automatico o un updater separato?
  • Il vendor pubblica versioni, note di rilascio e una procedura di rollback?
  • Esiste una modalità standard di Windows che evita il software proprietario?
  • Su quale macchina viene provato il prossimo aggiornamento?

La risposta non deve essere sempre “vietato”. Una tastiera programmabile, un dock o un dispositivo accessibile possono dipendere davvero dal software del produttore. La policy serve a distinguere la funzione necessaria dal pacchetto installato per abitudine.

Come misurare se il processo funziona

Contare le macchine aggiornate non basta. Misura i riavvii inattesi per 100 dispositivi, il tempo medio tra segnalazione e contenimento, il numero di utility privilegiate senza proprietario e la percentuale di update passati dal pilota. Per una flotta piccola puoi usare numeri assoluti: crash del mese, PC coinvolti, ore perse e modifiche senza rollback documentato.

Dopo il caso, chiudi anche il debito. Rimuovi utility non necessarie, aggiorna l’inventario, rimetti in servizio i workaround quando non servono più e controlla la pagina Windows Release Health finché Microsoft non cambia lo stato da “Investigating”. Un workaround lasciato per mesi diventa una configurazione misteriosa che il prossimo tecnico dovrà spiegare da zero.

Cosa fare oggi

Se non hai visto i sintomi, non applicare la modifica al registro “per sicurezza”. Verifica invece quante utility di periferica sono installate e quali caricano driver. Scegli una macchina pilota per i prossimi aggiornamenti Windows e assegna un proprietario alle applicazioni con privilegi amministrativi.

Se i crash sono già presenti, parti dalla timeline e dalla query di sola lettura. Confronta il risultato con la pagina ufficiale, conserva gli eventi, prova la mitigazione su un solo dispositivo e prepara il rollback. La differenza tra tentativo e procedura sta qui: ogni passaggio deve dirti cosa hai osservato, cosa hai cambiato e come torni indietro.

Fonti