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

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

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

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

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

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

Перевірено: 18.09.2026 · Оновлено: 25.09.2026 · Зачеплено: Windows Server 2019 / 2022 / 2025 (а також 2016, 2012 R2, 2012) · Виправлення: KB5129237 (Server 2022) та відповідні позачергові оновлення · Статус: виправлено Microsoft

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

• Нові 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 секунд.

Що стоїть за кожним симптомом

Коли це, найімовірніше, НЕ цей випадок

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

• збірка системи не та, що вказана в таблиці проблемних оновлень нижче (для Server 2022 проблемна саме 20348.5622);

• подій 7011 немає або вони не йдуть парами з ритмом 30 секунд;

• зависає вся віртуальна машина, включно з консоллю гіпервізора, або гіпервізор показує завантаження процесора чи затримки сховища, що впираються в стелю;

• служби віддалених робочих столів у стані Stopped, а не Running;

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

Мінімальний набір ознак саме цієї регресії: проблемна збірка + роль RDS + пари подій 7011 + зависання на нових входах і завершеннях сеансів при нормальних ресурсах.

Хронологія інциденту

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

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

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

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

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

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

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

Про цей аналіз. Інцидент розслідувала команда IT Master на двох незалежних продуктивних серверах різних клієнтів. Висновки спираються на журнали подій і дампи служб TermService, SessionEnv та UmRdpService, зняті під час збою 16.09.2026 з 11:04 до 11:06.

Як ми зловили момент збою

Ручний перебір версій два дні давав лише здогадки. Тому ми написали невеликий монітор на PowerShell і зареєстрували його як заплановане завдання. Кожні 30 секунд він записує в журнал:

• час відгуку WMI (поріг тривоги 2 секунди);

• чи відповідає qwinsta за відведений час;

• кількість сеансів і стан служб RDS;

• кількість дескрипторів і розмір пулів памʼяті ядра.

При першій ознаці деградації монітор автоматично збирає пакет доказів: активність WMI, таймаути служб, список процесів і сеансів, стан служб, ресурси ядра, журнал терміналу, профілі, а також повні дампи служб UmRdpService, SessionEnv і TermService через procdump.

Ключова перевірка проста: запустити qwinsta в окремому процесі й не чекати на неї довше за таймаут. Спрощено це виглядає так:

$job = Start-Job { qwinsta }
if (-not (Wait-Job $job -Timeout 15)) {
    # qwinsta не відповіла: фіксуємо деградацію і знімаємо дампи
    $svcPid = (Get-CimInstance Win32_Service -Filter "Name='TermService'").ProcessId
    & procdump64.exe -accepteula -ma $svcPid "D:\evidence\TermService.dmp"
}
Remove-Job $job -Force

Результат виправдав пів години роботи. 16.09 о 11:03:46 монітор зафіксував зависання qwinsta, на шість секунд раніше, ніж у журналі System зʼявилася перша подія 7011. Отже, спершу став термінальний стек, а служби посипалися вже слідом. Друге спрацювання, о 11:13:09, сталося через хвилину після старту сервера.

Одна річ, яку ми зробили б інакше: дампи знімалися послідовно, по хвилині на кожен, і TermService, найважливіший, ішов останнім, о 11:06:55. Для аналізу цього вистачило, але в наступній версії монітора головна служба знімається першою.

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

Дампи ми відкрили в консольному відладнику 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 потоків. Для порівняння, той самий сервер у робочий день із 30 користувачами тримає близько 450 тисяч дескрипторів і 13 тисяч потоків. Сервер завис майже порожнім, коли користувачі ще не встигли зайти після ранкового старту. Жодних витоків, жодного вичерпання пулів ядра. Усі служби в стані Running, просто всі стоять.

Отже, розділимо два твердження. Що ми бачимо в дампі: очікування без таймауту всередині WDLIB_Close під час завершення RDP-сеансу, за увімкненого прапорця 3802373433. Що підтверджує Microsoft: це регресія вересневого накопичувального оновлення, про неї нижче.

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

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

У таблиці вище лише ті версії, для яких відомий номер проблемного оновлення. Microsoft зазначає, що дефект зачепив також Windows Server 2016, 2012 R2 і 2012, позачергові виправлення для них наведені в таблиці нижче.

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

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

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

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

Для Windows Server 2025 з увімкненим hotpatch є окремий варіант: оновлення KB5129241 потребує вже встановленого KB5124008 від 8 вересня і ставиться без перезавантаження.

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

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

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 і 5,6%), а потім одразу видати повідомлення про успішне завершення. Це нормально.

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. І головне: перевіряйте саме нові підключення, а не відновлення наявних сеансів. Збій проявлявся тільки на нових входах і завершеннях.

4. Підтвердіть, що дефект пішов

Через кілька годин роботи з користувачами порахуйте події 7011 від моменту останнього старту:

$boot = (Get-CimInstance Win32_OperatingSystem).LastBootUpTime
Get-WinEvent -FilterHashtable @{LogName='System'; Id=7011; StartTime=$boot} -ErrorAction SilentlyContinue | Measure-Object

Нуль подій і qwinsta, яка відповідає миттєво, означають, що виправлення працює. У нас на сервері А до оновлення було 13 подій 7011 за три хвилини ранкового збою, після старту на збірці 5631 за 20 годин не зʼявилося жодної.

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

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

Це саме обхідний шлях. Є повідомлення адміністраторів на Microsoft Q&A про те, що після застосування KIR 260911_18471 проблема поверталася. Це ще один аргумент ставити саме позачергове оновлення, а не покладатися на політику.

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

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

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

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

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

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

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

FAQ

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

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

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

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

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

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

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

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

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

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

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

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

Які версії Windows Server зачепило?

Підтверджені проблемні оновлення відомі для Windows Server 2019 (KB5122876), 2022 (KB5122882) і 2025 (KB5122871). Microsoft зазначає вплив і на Windows Server 2016, 2012 R2 та 2012, для них теж випущені позачергові виправлення. Дефект проявляється на системах з роллю віддалених робочих столів: саме там задіяний сценарій завершення сеансу, у якому живе регресія.

Чи виправляє KB5129237 проблему остаточно?

Так. Це не тимчасовий обхід, а виправлення самого коду: оновлення прибирає очікування без таймауту в процедурі завершення сеансу. Воно накопичувальне, тому містить і всі вересневі патчі безпеки. Після встановлення збірка Server 2022 має стати 20348.5631. На обох серверах, які ми супроводжували, після оновлення збій більше не повторювався.

Чи достатньо групової політики Known Issue Rollback?

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

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

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

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

Джерела

• Microsoft Support — KB5129237 (OS Build 20348.5631), позачергове оновлення для Windows Server 2022

• Microsoft Learn — Windows Server 2022, стан версії та відомі проблеми

• Microsoft Support — історія оновлень Windows Server 2022

• Власний аналіз дампів TermService, SessionEnv і UmRdpService, знятих 16.09.2026 з 11:04 до 11:06, та журналів моніторингу (IT Master)