Термінальний сервер зависає після вересневого оновлення Windows: розбір інциденту з дампами

Термінальний сервер перестав пускати людей. Винним виявилося оновлення безпеки.

14 вересня 2026 року о 14:00 термінальний сервер одного з наших клієнтів перестав приймати нові підключення. Ті, хто вже працював, продовжували працювати. Нові сеанси зависали на екрані «Зачекайте, триває запуск Настройка сервера удалённых рабочих столов» і далі не йшли.

Диспетчер завдань не відкривався. Штатне перезавантаження не проходило: команда завершення роботи просто зависала. Допомогло лише апаратне скидання через гіпервізор. Наступного ранку все повторилося, потім ще раз, уже через півгодини після старту. Інтервал між відмовами скорочувався.

Через два дні така сама картина зʼявилася на сервері зовсім іншого клієнта. Різні компанії, різне програмне забезпечення, різна інфраструктура, і однаковий збій. Саме це і вивело на справжню причину.

Нижче повний розбір: як упізнати проблему, куди ми йшли хибним шляхом, що показали дампи процесів, зняті прямо в момент зависання, і як це лікується.

Симптоми, за якими впізнати проблему

• Нові RDP-підключення зависають на «Please wait for the Remote Desktop Configuration» або на етапі привітання

• Наявні сеанси працюють, але не можуть коректно завершитися

• Не відкривається диспетчер завдань

• Зависають команда qwinsta, консоль MMC, засіб діагностики ліцензування RDS, іноді Провідник

• Штатне перезавантаження не проходить, допомагає тільки апаратне скидання

• У журналі System зʼявляються події 7011 про перевищення часу очікування 30000 мс від служб NlaSvc, iphlpsvc, UmRdpService

Перевірити наявність подій можна однією командою PowerShell:

Get-WinEvent -FilterHashtable @{LogName='System'; Id=7011; StartTime=(Get-Date).AddHours(-24)} |
    Select-Object TimeCreated, @{n='Служба'; e={ ($_.Message -replace '\s+',' ') }} | Format-Table -Wrap

Характерна ознака: події йдуть парами з інтервалом рівно в 30 секунд.

Куди ми йшли хибним шляхом

Розповідаємо чесно, бо це корисніше за красиву історію успіху. На пошук причини пішло два дні, і більшу частину цього часу ми перевіряли версії, які виявилися хибними.

Перевірили та відкинули: вільне місце на сховищі й на дисках гостьової системи, ресурси гіпервізора, знімки віртуальної машини, продуктивність дискової підсистеми, DNS, доступність контролера домену, ліцензування RDS, IPv6, службу IP Helper, підсистему тіньових копій, розмір репозиторію WMI, витоки дескрипторів і памʼяті ядра.

Окремо перевіряли агент резервного копіювання: він створював циклічні підписки WMI, які завершувалися з помилкою скасування. Версія виглядала переконливо, але після повного вимкнення агента проблема повернулася.

Оманливою була й мігруюча симптоматика. Одного разу сервер завис на запуску Windows Search, іншого на завантаженні профілю користувача, третього на налаштуванні RDS. Складалося враження, що ламається щось спільне під усіма службами.

Ключовий поворот. Та сама картина зʼявилася на сервері іншого клієнта. Одна машина могла зламатися зі своєї причини. Дві незалежні, з різним програмним забезпеченням, навряд чи. Залишалося єдине спільне: обидві отримали той самий набір вересневих оновлень.

Що показали дампи

Щоб не будувати здогадки, ми налаштували монітор, який щохвилини перевіряє відгук системи і при першій ознаці зависання автоматично знімає дампи ключових служб. Наступного разу він спрацював о 11:03:46, за шість секунд до першої події 7011 у журналі. Дампи трьох служб, TermService, SessionEnv і UmRdpService, захопили самий початок відмови.

Далі ми відкрили їх у консольному відладнику cdb із символами з серверів Microsoft. Версія RDPSERVERBASE.dll у дампі: 10.0.20348.5622, тобто саме та збірка, у якій живе регресія.

Автоматичний аналіз дає хибний слід

Перше, що робить більшість адміністраторів, це запускає автоматичний аналіз. Ми теж почали з нього:

!analyze -v -hang

Відладник вказав на потік 68c зі стеком sechost!ScSendResponseReceiveControls і записав це у висновок про збій. Це хибний слід. Так виглядає звичайний потік диспетчера служб, який штатно чекає команд від SCM. Справжнього винуватця видно лише в повному переліку потоків через ~*k.

Заблокований потік

У процесі TermService (svchost, PID 1672) зі 125 потоків заблокований рівно один, номер 111. Ось його стек, дослівно з відладника:

ntdll!NtWaitForAlertByThreadId+0x14
ntdll!RtlpWaitOnAddressWithTimeout+0x9f
ntdll!RtlpWaitOnAddress+0xd8
ntdll!RtlWaitOnAddress+0x13
RDPSERVERBASE!WDLIB_Close+0x98
RDPSERVERBASE!CRDPWDUMXStack::WDCloseStack+0x12a
RDPSERVERBASE!CRDPWDUMXStack::OnIcaCommand+0x3dc
RDPSERVERBASE!CRDPWDUMXStack::WDCallback_IcaChannelInput+0x131
RDPSERVERBASE!WDICART_IcaChannelInput+0x1f
RDPSERVERBASE!ShareClass::DCS_ReceivedShutdownRequestPDU+0x17c
RDPSERVERBASE!ShareClass::SC_OnDataReceived+0x2f4

Читати треба знизу вгору. Клієнт надіслав пакет завершення сеансу, це рядок DCS_ReceivedShutdownRequestPDU. Сервер почав зносити стек драйверів сеансу, це WDCloseStack. І застряг усередині WDLIB_Close на виклику RtlWaitOnAddress.

Очікування без таймауту

Дизасемблювання самої функції показує механіку дефекту. Перед очікуванням перевіряється внутрішній прапорець функціональності, а четвертий аргумент RtlWaitOnAddress, тобто таймаут, обнуляється інструкцією xor:

call  RDPSERVERBASE!wil::details::FeatureImpl<__WilFeatureTraits_Feature_3802373433>::__private_IsEnabled
test  al,al
je    RDPSERVERBASE!WDLIB_Close+0xa7   ; прапорець вимкнено, очікування пропускається
...
xor   r9d,r9d                          ; Timeout = NULL, чекати вічно
lea   rdx,[rsp+40h]
mov   rcx,rdi
lea   r8d,[r9+4]
call  qword ptr [RDPSERVERBASE!_imp_RtlWaitOnAddress]

NULL у полі таймауту означає очікування без обмеження в часі. Потік стоятиме доти, доки хтось його не розбудить, а будити нікому.

І оскільки в дампі потік перебуває вже за розвилкою je, ми точно знаємо: прапорець на цьому сервері був увімкнений. Це не припущення, це траєкторія виконання.

Деталь, що замикає картину. Прапорець у коді має ідентифікатор 3802373433. Це той самий номер, який фігурує в механізмі відкоту відомої проблеми від Microsoft. Тобто бінарник прямо вказує на перемикач, яким виробник і гасить дефект.

Чому один потік кладе весь сервер

Сам по собі завислий потік це дрібниця. Проблема в тому, що він устиг захопити критичну секцію обʼєкта сеансу і вже ніколи її не віддасть. Відладник підтверджує: секція за адресою 0x21ff13f2fc0 заблокована, лічильник блокувань 2, власник, потік c030, той самий номер 111.

Зміни стану сеансів у Windows обробляються послідовно, один за одним. Тому наступний логофф чекає на попередній. У дампі SessionEnv це видно як на долоні: із 32 потоків 24 стоять в обробнику логоффа, і кожен завис на функції WinStationEnumerateW, чекаючи відповіді від TermService через ALPC. Це та сама функція, яку викликає qwinsta. Ось чому вона переставала відповідати.

Коли пул потоків SessionEnv вичерпано, служба більше не здатна налаштувати жоден новий сеанс. Саме тому нові підключення застрягали на написі «Настройка сервера удаленных рабочих столов».

Картину підтверджують і прості дані, без відладника. У знімку процесів 25 сеансів висять з однаковим набором: LogonUI, dwm, fontdrvhost, winlogon. Жодного explorer, жодної програми користувача. Журнал уже відрапортував про успішний вихід, а сеанси фізично живі ще дві хвилини потому.

Третій дамп, UmRdpService, показує масштаб наслідків. Сама служба ні на чому не заблокована, у неї просто лишилися живі цикли перенаправлення пристроїв для сеансів, яких формально вже не існує. Вона чесно обслуговує принтери й диски користувачів, що пішли пʼять хвилин тому, бо ніхто не сказав їй зупинитися.

Звідси ж і відповідь на питання, чому не допомагав перезапуск служби та штатне завершення роботи. Зупинити TermService неможливо, поки в ньому є потік у вічному очікуванні. Диспетчер служб чекає на відповідь, не отримує її, і процедура вимкнення зупиняється на тому самому місці. Залишається апаратне скидання.

Ресурси тут ні до чого

Окремо варто сказати про те, чого в дампах немає. На момент збою: 80 ГБ вільної памʼяті з 96, 277 процесів, 132 тисячі дескрипторів, 4448 потоків. Для порівняння, на здоровому сервері під повним навантаженням дескрипторів було втричі більше. Жодних витоків, жодного вичерпання пулів ядра. Усі служби в стані Running, просто всі стоять.

Причина одна і вона точкова: виклик очікування без таймауту в коді завершення сеансу.

Справжня причина

Вересневе накопичувальне оновлення безпеки KB5122882 для Windows Server 2022 (збірка 20348.5622) містить регресію в службі віддалених робочих столів. Microsoft офіційно визнала проблему. Вона торкнулася не тільки Windows Server 2022:

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

Рішення: позачергове оновлення

14 вересня Microsoft випустила позачергові оновлення, які виправляють регресію:

Важливо. Оновлення накопичувальні, вони вже містять усе з вересневого пакета. Видаляти проблемне оновлення перед установкою не потрібно і не рекомендується: відкат прибрав би й патчі безпеки.

Через Windows Update виправлення зазвичай не приходить. Завантажувати треба вручну з Microsoft Update Catalog.

Як встановити: покроково

1. Перевірте поточну збірку

(Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion').UBR

Якщо для Server 2022 показує 5622, ви на проблемній версії.

2. Встановіть через DISM, а не через стандартний інсталятор

Це практична порада з нашого досвіду. Стандартний інсталятор wusa.exe на зачепленому сервері може зависнути на етапі підготовки й не зрушити з місця годинами. У нас так і сталося: процеси стояли з нульовим навантаженням, журнал CBS не поповнювався.

Надійніший шлях, розпакувати пакет і встановити через DISM:

mkdir C:\INSTALL\kb5129237
expand -F:* "C:\INSTALL\windows10.0-kb5129237-x64_ХЕШ.msu" C:\INSTALL\kb5129237
dism /Online /Add-Package /PackagePath:"C:\INSTALL\kb5129237\Windows10.0-KB5129237-x64.cab" /NoRestart

Граблі. DISM не приймає файл .msu напряму і поверне помилку 0x80070032. Потрібен саме .cab, витягнутий із нього командою expand. Ще одна особливість: шкала прогресу може завмерти на кількох відсотках, а потім одразу видати повідомлення про успішне завершення. Це нормально.

3. Перезавантажте і перевірте результат

Переконайтеся, що система чекає на перезавантаження:

Test-Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending'

Після старту система дозавантажить пакет на екрані завантаження, це може зайняти 10 до 20 хвилин. Переривати не можна. Далі перевірка:

(Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion').UBR
Get-HotFix -Id KB5129237

Збірка має стати 5631. І головне: перевіряйте саме нові підключення, а не відновлення наявних сеансів. Збій проявлявся тільки на нових входах.

Тимчасовий обхід, якщо оновитися зараз не виходить

Microsoft випустила також механізм відкоту відомої проблеми через групову політику. Для Windows Server 2022 це політика з ідентифікатором 260911_18471, що застосовується в розділі Computer Configuration, Administrative Templates. По суті вона вимикає той самий прапорець функціональності, який ми бачили в дизасемблюванні.

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

Які висновки ми зробили

Симптом, що мігрує між службами, це привід запідозрити спільний знаменник. Коли зависає то одна підсистема, то інша, а кожна окремо здорова, шукати треба не в них.

Друга однакова відмова на незалежній системі важливіша за десяток перевірених версій. Саме вона перевела нас від перебору здогадок до правильної відповіді.

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

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

FAQ

Як швидко зрозуміти, що у мене саме ця проблема?

Дві перевірки. Подивіться збірку системи: для Server 2022 проблемна це 20348.5622. Потім перевірте журнал System на наявність подій 7011 від служб NlaSvc та iphlpsvc, що йдуть парами з інтервалом 30 секунд. Якщо збіглося і те, і інше, це той самий випадок.

Чи можна просто видалити проблемне оновлення?

Технічно так, але не варто. Відкат прибере всі вересневі патчі безпеки, зокрема виправлення критичних вразливостей. Позачергове оновлення накопичувальне: воно ставиться поверх і містить усе потрібне.

Чи торкається проблема звичайних робочих станцій?

Симптом проявляється на серверах із роллю віддалених робочих столів. Для клієнтських версій Windows Microsoft також випустила позачергові оновлення, але масових скарг на зависання робочих станцій не було.

Скільки часу займає встановлення виправлення?

Саме встановлення через DISM близько 20 до 40 хвилин, плюс перезавантаження з дозавантаженням пакета ще 10 до 20 хвилин. Плануйте вікно приблизно на годину і попереджайте користувачів заздалегідь.

Чому перезавантаження допомагало лише на деякий час?

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

Чи можна відтворити цей аналіз у себе?

Так. Потрібен procdump із набору Sysinternals і консольний відладник cdb із компонента Debugging Tools for Windows. Дамп знімається командою procdump64.exe -accepteula -ma dump.dmp, відкривається через cdb.exe -z dump.dmp -y "srv*C:\symbols*https://msdl.microsoft.com/download/symbols", далі команда ~*k показує стеки всіх потоків. Графічний WinDbg із Microsoft Store консольного cdb не містить, потрібен саме SDK-компонент.

Якщо у вас така сама проблема

Ми супроводжуємо термінальні сервери, віртуальну інфраструктуру та мережі бізнесу в Одесі й по Україні. Якщо ваш RDS-сервер поводиться описаним чином, напишіть нам: підкажемо або візьмемо роботу на себе.

Перевірка займе хвилину. Подивіться збірку системи й наявність подій 7011 у журналі. Якщо симптоми збіглися, у вас той самий випадок, і виправлення вже існує.

Джерела

• Microsoft Support, KB5122882 (OS Build 20348.5622), розділ відомих проблем

• Microsoft Support, KB5129237 (OS Build 20348.5631), позачергове оновлення від 14.09.2026

• Microsoft Learn, Windows Server 2022 known issues and notifications

• Власний аналіз дампів TermService, SessionEnv і UmRdpService, зняті 16.09.2026 об 11:03