La configurazione perfetta e il killer silenzioso

Non avevo in programma di passare diverse notti a fare il debug di un demone RGB impazzito. Non avevo in programma di scrivere una suite diagnostica, un watchdog, un motore di trend e un monitor in background per Windows. E sicuramente non avevo in programma di diventare un esperto involontario del comportamento di rete di ASUS LightingService.

Era tardi, una di quelle notti tranquille in cui il mondo sembra in pausa e hai finalmente il tempo di respirare. Stavo lavorando sul mio ASUS Zephyrus G14, una macchina che amo sinceramente. È elegante, compatto, potente (e quindi super caldo durante le sessioni di gioco) e di solito incredibilmente affidabile. Ma nel corso di diverse settimane, ho iniziato a notare strani comportamenti che interrompevano il mio flusso di lavoro.

È iniziato tutto in modo silenzioso. Il mouse balbettava per una frazione di secondo. L’illuminazione RGB sul telaio sfarfallava o si bloccava completamente. Armoury Crate, il centro di controllo ASUS, diventava del tutto insensibile o smetteva di mostrare le informazioni di monitoraggio del sistema. Il sistema sembrava “pensare troppo” senza alcun motivo apparente.

All’inizio non ci ho fatto caso. Sappiamo tutti che Windows a volte fa cose strane in background: forse stava indicizzando dei file o il launcher di un gioco si stava aggiornando silenziosamente. Ma poi, una notte, mentre chattavo con un amico su Discord e aprivo i link che mi condivideva, il sistema ha restituito un errore di esaurimento del buffer TCP – ERR_NO_BUFFER_SPACE. Era qualcosa che non avevo mai visto prima su un laptop moderno. Inizialmente, i miei browser web semplicemente non aprivano determinate pagine. Poco dopo, hanno iniziato a mostrare lo stesso errore di buffer per ogni sito web, impedendo infine a qualsiasi applicazione che richiedesse una connessione Internet di comunicare con i propri server. Stranamente, le connessioni Wi-Fi e LAN funzionavano perfettamente e tutti gli altri dispositivi sulla rete comunicavano senza problemi. È stato in quel momento che ho capito che c’era qualcosa di profondamente, fondamentalmente sbagliato. Non era un normale glitch di Windows; era un fallimento sistemico.

L’inizio della caccia: giocare a fare il detective

Ho aperto tutti gli strumenti diagnostici a mia disposizione: Resource Monitor, Process Explorer, PowerShell e i comandi netstat standard. Ho iniziato a scavare come un detective in un vicolo buio, cercando qualsiasi indizio che potesse spiegare il collo di bottiglia della memoria e della rete.

Alla fine, sono riuscito a scoprire il servizio che causava il problema: LightingService.exe (il controller RGB di ASUS) stava aprendo connessioni TCP. Non una. Non dieci. Centinaia. Ogni pochi secondi, veniva generata un’altra connessione. E questa era la fregatura: nessuna di queste si chiudeva mai. Era come guardare un rubinetto gocciolare in un secchio che non si svuotava mai. Alla fine, il secchio traboccava, lo stack TCP/IP si bloccava e il mio sistema si congelava. Sono rimasto seduto lì, incredulo. LightingService dovrebbe controllare i LED locali. Perché mai stava comunicando tramite TCP e perché stava perdendo socket in modo così aggressivo?

L’illusione di una soluzione facile

Prima di ricorrere a misure drastiche, volevo trovare una soluzione facile e veloce per LightingService, quindi ho iniziato a cercare su Google. Pensavo dovesse esserci un file di configurazione in cui poter disabilitare questo inutile polling di rete.

Ho cercato in ogni possibile directory ASUS sul mio disco: Program Files, ProgramData, AppData Local e Roaming. Ho cercato file .config, .json, .xml, .ini, .properties… qualsiasi cosa potesse controllare la rete, la telemetria o il comportamento dei socket.

Dopo un paio d’ore, non ho trovato assolutamente nulla.

Alla fine, ho scoperto che ASUS aveva compilato LightingService con impostazioni hardcoded. Tutto era sepolto all’interno di eseguibili e DLL compilati in formato binario, come AuraService.dll. Ho considerato per un attimo il reverse-engineering o la modifica esadecimale dei binari, ma sarebbe stato insicuro e instabile. Ho persino pensato di disinstallare completamente Armoury Crate, ma non volevo perdere i controlli hardware che mi piacevano. Volevo una vera soluzione, non una resa.

Prendere in mano la situazione

Per capire l’entità del problema, ho scritto un rapido script PowerShell per contare le connessioni TCP collegate al PID di LightingService. Ho guardato i numeri salire come una marea lenta: 100, 200, 300, 500, 700. La perdita di socket era grave.

Una ricerca approfondita online ha confermato che non ero il solo. Decine di utenti su Reddit e sui forum ASUS con laptop Zephyrus, Strix e TUF segnalavano gli stessi identici crash. Dato che ASUS non rilasciava una patch e non volevo passare a soluzioni di terze parti come OpenRGB, SignalRGB, Polychromatic, Chromaify, WLED (Home Assistant), JackNet RGB Sync, Prismatik, Aurora, RGB Fusion (Gigabyte), iCUE (Corsair), Mystic Light (MSI) o Polychrome Sync (ASRock), ho deciso di sviluppare una soluzione che risolvesse la perdita TCP di LightingService e mi permettesse di continuare a utilizzare il software originale ASUS fino al rilascio di una patch ufficiale.

Il mio primo tentativo è stato un semplice script per terminare e riavviare il processo quando le connessioni diventavano troppe. Ma mi sono subito scontrato con un muro: terminare il processo non svuotava immediatamente il buffer TCP. I socket venivano lasciati in uno stato “TIME_WAIT” o trattenuti da processi figlio orfani. Il conteggio delle connessioni riprendeva esattamente da dove si era interrotto. Avevo bisogno di qualcosa di molto più intelligente.

La nascita di LightingWatchdog

Ho deciso di espandere il mio script in un’architettura modulare. Pezzo dopo pezzo, notte dopo notte, si è evoluto in un sistema completo. Ho creato moduli separati per Utilities, Diagnostics, Trends e per il ciclo principale di Watchdog.

Lo stato attuale del progetto è qualcosa di cui vado incredibilmente fiero. Dispone di rilevamento attivo delle perdite, monitoraggio della pressione del kernel e rilevamento delle tempeste WebSocket. Tiene traccia dei punteggi di salute e dell’analisi delle tendenze, esportando i dati in JSON e CSV. Cosa più importante, il ciclo del watchdog ora agisce come un guardiano in grado di autoguarirsi. Rileva la perdita, riavvia in sicurezza LightingService (utilizzando la corretta terminazione dell’albero dei processi per svuotare i socket inattivi), impone tempi di raffreddamento per prevenire tempeste di riavvii e monitora la deriva del clock.

Ho pubblicato lo strumento su GitHub per dare agli altri utenti ASUS un modo per mantenere intatti i loro RGB e la stabilità del sistema senza rinunciare ad Armoury Crate.

La roadmap futura: oltre lo script

Sebbene il motore PowerShell sia stabile, il viaggio non è finito. I miei obiettivi futuri per LightingWatchdog si concentrano sulla sua trasformazione da script in background a un’applicazione nativa standalone per Windows.

In primo luogo, ho intenzione di astrarre la configurazione in modo che possa monitorare qualsiasi applicazione che presenta perdite, non solo LightingService. Successivamente, miro a racchiudere il motore in un background worker C# .NET leggero, introducendo un’interfaccia nella barra delle applicazioni (System Tray) con indicatori visivi di salute (Verde/Giallo/Rosso). Infine, voglio migrare la logica di monitoraggio per utilizzare Event Tracing for Windows (ETW) per un tracciamento dei socket in tempo reale a zero overhead, il tutto pacchettizzato in un semplice programma di installazione in un solo clic.

Non mi sarei mai aspettato di diventare uno sviluppatore di watchdog per un controller RGB. Ma finché i fornitori non scriveranno software impeccabili, i progetti di questo tipo continueranno a motivarmi a migliorare la mia logica e le mie capacità di programmazione….

Aggiornamento 1 (05.09.2026)

Durante la mia indagine, ho esplorato altre potenziali soluzioni permanenti. Ho analizzato il dump TCP e ho scoperto che LightingService non stava cercando di comunicare con un server esterno; chiamava ripetutamente l’API Socket di Windows per vincolare socket locali (0.0.0.0) per poi abbandonarli. Poiché non stabiliva mai una vera trasmissione di rete, creare una rigida regola del Firewall di Windows per bloccare il traffico era del tutto inutile: i firewall bloccano il traffico di rete, non le allocazioni di memoria del kernel locale.

La community di appassionati ASUS suggerisce spesso un “permafix affidabile”: disinstallare completamente Armoury Crate e sostituirlo con G-Helper, una brillante alternativa open source. Sebbene G-Helper elimini la perdita alla fonte non utilizzando affatto LightingService, volevo mantenere le funzionalità ufficiali di Armoury Crate. Avevo bisogno di un guardiano per il software che già usavo, il che ha solo rafforzato la mia decisione di creare questo script.