Ідеальне налаштування та тихий вбивця

Я не планував витрачати кілька ночей на налагодження проблемного RGB-сервісв. Я не планував писати засіб для діагностики, watchdog, аналізатор тенденцій та повноцінний фоновий монітор для Windows. І я точно не планував стати мимовільним експертом із мережевої поведінки ASUS LightingService.

Вже було досить пізно — одна з тих тихих ночей, коли світ ніби зупиняється, і ти нарешті маєш час перевести подих. Я працював за своїм ASUS Zephyrus G14, машиною, яку я щиро люблю. Вона елегантна, компактна, потужна (і тому дуже гаряча під час ігрових сесій), і зазвичай неймовірно надійна. Але протягом кількох тижнів я почав помічати дивну поведінку, яка заважала моєму робочому процесу.

Усе почалося непомітно. Мишка могла «заїкатись» на частку секунди. RGB-підсвічування корпусу мерехтіло або повністю зависало. Armoury Crate, центр управління ASUS, ставав абсолютно нечутливим або переставав відображати інформацію моніторингу системи. Здавалося, що система «занадто багато думає» без видимих на те причин.

Спочатку я не звертав на це уваги. Усі ми знаємо, що Windows іноді робить дивні речі у фоновому режимі — можливо, йшло індексування файлів, або ігровий лаунчер тихо оновлювався. Але потім однієї ночі, коли я спілкувався з другом у Discord і відкривав посилання, якими він ділився зі мною, система видала помилку вичерпання TCP-буфера – ERR_NO_BUFFER_SPACE. Це було щось, чого я ніколи раніше не бачив на сучасному ноутбуці. Спочатку мої веб-браузери просто не відкривали певні сторінки. Згодом вони почали показувати ту саму помилку буфера для кожного веб-сайту, що зрештою призвело до того, що будь-яка програма, яка потребувала підключення до Інтернету, не могла зв’язатися зі своїми серверами. Дивно, але самі підключення Wi-Fi та LAN працювали ідеально, і всі інші пристрої в мережі обмінювалися даними без проблем. Саме в цей момент я зрозумів, що щось глибоко, фундаментально не так. Це був не стандартний збій Windows; це була системна помилка.

Початок полювання: гра в детектива

Я відкрив усі доступні мені інструменти діагностики: Resource Monitor, Process Explorer, PowerShell і стандартні команди netstat. Я почав копати, як детектив у темному провулку, шукаючи будь-які зачіпки, які могли б пояснити вразливість в пам’яті та мережі.

Зрештою, мені вдалося виявити службу, яка спричиняла проблему: LightingService.exe — контролер ASUS RGB — відкривав TCP-з’єднання. Не одне. Не десять. Їх були сотні. Кожні кілька секунд створювалося нове з’єднання. І найгірше: жодне з них ніколи не закривалося.

Це було схоже на те, як дивишся на кран, що капає у відро, яке ніколи не спорожняється. Зрештою, відро переповнилося, стек TCP/IP захлинувся, і моя система зависла. Я сидів і не міг у це повірити. LightingService має керувати локальними світлодіодами. Чому він взагалі спілкувався через TCP, і чому він так агресивно «витікав» сокетами?

Ілюзія легкого рішення

Перш ніж вдаватися до радикальних заходів, я хотів знайти просте і швидке рішення для LightingService, тому почав гуглити можливі варіанти. Я подумав, що повинен бути файл конфігурації, де я міг би відключити це непотрібне мережеве спілкування.

Я обшукав кожен можливий каталог ASUS на своєму диску: Program Files, ProgramData, AppData Local та Roaming. Я шукав .config, .json, .xml, .ini, .properties — будь-що, що могло б керувати мережею, телеметрією або поведінкою сокетів.

Після кількох годин пошуків я не знайшов абсолютно нічого.

Зрештою я виявив, що ASUS скомпілювала LightingService із жорстко закодованими налаштуваннями. Усе було заховано всередині бінарно-скомпільованих виконуваних файлів та DLL, таких як AuraService.dll. Я на мить задумався про зворотну розробку або шістнадцяткове редагування бінарників, але це було б елегантним чи стабільним рішенням. Я, навіть, розглядав можливість повного видалення Armoury Crate, але не хотів втрачати елементи керування обладнанням, які мені дійсно подобалися. Я хотів реального покращення ситуації, і не хотів здаватися так просто.

Беру справу у свої руки

Щоб зрозуміти масштаб проблеми, я написав швидкий, чорновий скрипт PowerShell для підрахунку TCP-з’єднань, прив’язаних до PID LightingService. Я спостерігав, як цифри зростають, наче повільний приплив: 100, 200, 300, 500, 700. Витік сокетів був серйозним.

Ретельний пошук в Інтернеті підтвердив, що не я один мав таку проблему. Десятки користувачів Reddit та форумів ASUS із ноутбуками Zephyrus, Strix та TUF повідомляли про ті самі збої. Оскільки ASUS не випускала патч, і я не хотів переходити на сторонні рішення, такі як OpenRGB, SignalRGB, Polychromatic, Chromaify, WLED (Home Assistant), JackNet RGB Sync, Prismatik, Aurora, RGB Fusion (Gigabyte), iCUE (Corsair), Mystic Light (MSI) або Polychrome Sync (ASRock) — я вирішив розробити рішення, яке виправило б витік TCP у LightingService і дозволило б мені продовжувати використовувати оригінальне програмне забезпечення від ASUS, поки вони не випустять офіційний патч.

Моєю першою спробою був простий скрипт для завершення та перезапуску процесу, коли кількість з’єднань ставала завеликою. Але я швидко натрапив на стіну: завершення процесу не одразу очищало TCP-буфер. Сокети залишалися у стані TIME_WAIT або дочірні процеси блокували виконання скрипту. Кількість з’єднань, після перезапуску сервісу, просто відновлювалася з того місця, де зупинилася перед зупинкою сервісу. Мені потрібно було знайти набагато дієве рішення.

Народження LightingWatchdog

Я вирішив вдосконалити свій скрипт і переробити його у модульну архітектуру. Крок за кроком, ніч за ніччю, він перетворився на повноцінну систему. Я створив окремі модулі для Утиліт, Діагностики, Аналізу тенденцій (Trends) та основного циклу Watchdog.

Поточний стан проекту — це те, чим я неймовірно пишаюся. Він має функції активного виявлення витоків, моніторингу навантаження на ядро та виявлення WebSocket-штормів. Він відстежує оцінку працездатності та аналізує тенденції, експортуючи дані в JSON та CSV. Що найважливіше, цикл watchdog тепер діє як вартовий із функцією самовідновлення. Він виявляє витік, безпечно перезапускає LightingService (використовуючи правильне завершення дерева процесів для скидання «мертвих» сокетів), застосовує час охолодження для запобігання штормам перезапусків та відстежує дрейф годинника.

Я опублікував інструмент на GitHub, щоб дати іншим користувачам ASUS можливість зберегти своє RGB-підсвічування та стабільність системи, не відмовляючись від Armoury Crate.

Плани на майбутнє: більше, ніж просто скрипт

Хоча PowerShell і працює стабільно, подорож ще далеко не завершена. Мої майбутні цілі щодо LightingWatchdog зосереджені на перетворенні його з фонового скрипта на рідну автономну програму для Windows.

По-перше, я планую абстрагувати конфігурацію, щоб вона могла відстежувати будь-яку програму, що дає витік, а не лише LightingService. Далі я прагну загорнути скррипт у легкий фоновий процес C# .NET, додавши інтерфейс для роботи із System Tray із візуальними індикаторами працездатності (Зелений/Жовтий/Червоний). Нарешті, я хочу перенести логіку моніторингу на використання Event Tracing for Windows (ETW) для відстеження сокетів у реальному часі з нульовими витратами ресурсів, упакувавши все це в простий інсталятор, який розпакує застосунок в один клік.

Я ніколи не очікував, що стану розробником watchdog для RGB-контролера. Але поки розробники не почнуть писати бездоганне програмне забезпечення, проекти такого типу і надалі мотивуватимуть мене вдосконалювати свою логіку та навички програмування….

Доповнення 1 (05.09.2026)

Під час свого розслідування я досліджував інші потенційні постійні рішення. Я проаналізував дамп TCP і виявив, що LightingService не намагався зв’язатися із зовнішнім сервером; він раз за разом викликав Windows Socket API, щоб прив’язати локальні сокети (0.0.0.0), а потім просто їх залишав. Оскільки він ніколи не встановлював справжню мережеву передачу, створення суворого правила Windows Firewall для блокування трафіку було абсолютно марним — брандмауери блокують мережевий трафік, а не локальні виділення пам’яті ядра.

Спільнота ентузіастів ASUS часто пропонує надійний варіант – повністю видалити Armoury Crate і замінити його на G-Helper, чудову альтернативу з відкритим вихідним кодом. Хоча G-Helper усуває витік у самому корені, оскільки взагалі не використовує LightingService, я хотів зберегти офіційні функції Armoury Crate. Мені потрібен був захисник для програмного забезпечення, яким я вже користувався, що лише зміцнило моє рішення створити цей скрипт.