Situatie
Windows Update are obiceiul de a provoca probleme, iar de data aceasta este vorba despre Remote Desktop Services = Serviciul de desktop la distanță. Gazdele de sesiune funcționează fără probleme câteva ore după repornire, dar apoi conexiunile rămân blocate la „Connecting…”, utilizatorii nu se pot deconecta, iar în cele din urmă singura soluție este o resetare forțată.
Revenirea la versiunea anterioară a actualizării este adesea cea mai simplă soluție, dar versiunea lansată luna Septembrie 2026 remediază vulnerabilitatea CVE-2026-69525, o vulnerabilitate critică de tip RCE = de execuție a codului la distanță pentru Serviciile de desktop remote, cu un scor CVSS de 9,8, plus două vulnerabilități de tip zero-day care sunt deja exploatate activ. Așadar, revenirea la versiunea anterioară s-ar putea să nu fie cea mai bună opțiune.
Ce se întâmplă
Mai mulți administratori au descris același tipar de eroare si anume ca gazdele sesiunilor RDS funcționează normal după o repornire, apoi se blochează câteva ore mai târziu, când utilizatorii încep să se deconecteze.
Odată ce problema apare, noile conexiuni RDP rămân blocate la „Connecting…” și nu ajung niciodată la ecranul de autentificare. Sesiunile existente nu se pot deconecta corect. Task Manager, Setări și majoritatea instrumentelor care interacționează cu starea sesiunii intră în blocaj, deoarece nu pot obține un răspuns de la Local Session Manager (LSM). Chiar și o repornire normală se blochează. Numai o resetare forțată restabilește funcționarea gazdei.
Problema pare să fie legată de o rutină numită RDPSERVERBASE!WDLIB_Close, care este apelată în timpul închiderii sesiunii. Atunci când un anumit indicator de funcționalitate intern(3802373433) este activ, această rutină apelează funcția RtlWaitOnAddress fără limită de timp, ceea ce determină firul de execuție să aștepte pe termen nelimitat.
Deoarece LSM serializează modificările stării sesiunii printr-o singură secțiune critică, acel thread blocat blochează tot ce se află în aval de el = conexiuni noi, deconectări și solicitări către broker, până când host-ul este resetat forțat.
Acestea sunt semnăturile si avertismentele din jurnalul de evenimente care indică această eroare specifică:
- Eveniment 20498 din TerminalServices-RemoteConnectionManager: „Remote Desktop Services has taken too long to complete the client connection”
- Eveniment 6005 din Winlogon: „The winlogon notification subscriber SessionEnv is taking long time to handle the notification event (Disconnect)”
- Starea TermService: StopPending în loc de Running
Problema afectează toate versiunile actuale de Windows Server prin intermediul actualizărilor cumulative din septembrie 2026.
De ce revenirea la o versiune anterioară este o soluție de ultimă instanță
Aceeași actualizare care a provocat defecțiuni la RDS a remediat și vulnerabilitatea CVE-2026-69525, o vulnerabilitate critică de execuție a codului la distanță în Serviciile de desktop la distanță, cu un scor CVSS de 9,8. Versiunea din septembrie a remediat, de asemenea, vulnerabilitățile CVE-2026-81963(Windows Update) și CVE-2026-85880 (Windows Advanced Local Procedure Call), ambele fiind vulnerabilități de tip „zero-day” deja exploatate activ și incluse în catalogul CISA al vulnerabilităților cunoscute ca fiind exploatate.
Dacă serverele RDS sunt utilizate doar intern și nu sunt expuse la internet, riscul este mai mic, iar revenirea la versiunea anterioară ar putea fi cea mai simplă opțiune. Însă, dacă serverul RDS este accesibil de pe internet, revenirea la versiunea anterioară ar trebui să fie ultima soluție.
Solutie
Înainte de orice, asigurați-vă mai întâi că pachetul de actualizare/update(KB) relevant este instalat și că jurnalul de evenimente corespunde exact acestei defecțiuni, și nu altcuiva.
Verificați versiunea instalată:
$cv = Get-ItemProperty “HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion”
“$($cv.CurrentBuild).$($cv.UBR)”
Pentru Windows Server 2022, versiunea afectată este 20348.5622. Pentru Windows Server 2025 este 26100.33438. Verificați EventViewer(jurnalul de evenimente) pentru a identifica semnăturile de eroare cunoscute:
# Event 20498 — RDP connection timeout
Get-WinEvent -FilterHashtable @{
LogName = ‘Microsoft-Windows-TerminalServices-RemoteConnectionManager/Admin’
Id = 20498
} -MaxEvents 5 -ErrorAction SilentlyContinue | Format-Table TimeCreated, Message -Wrap
# Event 6005 — SessionEnv disconnect notification timeout
Get-WinEvent -FilterHashtable @{
LogName = ‘System’
ProviderName = ‘Microsoft-Windows-Winlogon’
Id = 6005
} -MaxEvents 5 -ErrorAction SilentlyContinue | Format-Table TimeCreated, Message -Wrap
Verificați starea serviciului TermService:
Get-Service -Name TermService | Select-Object Name, Status
Starea „StopPending” este un indicator clar că blocajul este deja activ. Dacă jurnalul de evenimente nu conține înregistrări și TermService funcționează normal, înseamnă că host-ul fie nu a declanșat încă condiția respectivă, fie nu este afectat.
Remedierea problemei RDS implică dezactivarea indicatorului de funcționalitate defectuos
Pentru gazdele care sunt încă accesibile, abordarea recomandată este dezactivarea indicatorului de funcționalitate specific printr-o modificare a registrului. Această măsură menține instalate patch-urile de securitate din Septembrie și dezactivează doar calea de închidere a sesiunii defectuoase.
Nota Bene:
Dezactivarea acestui indicator anulează îmbunătățirea redirecționării audio RDP introdusă în actualizarea cumulativă (CU) din septembrie. Patch-urile de securitate din aceeași actualizare nu sunt afectate. Deoarece Microsoft nu a documentat public acest indicator, nu putem exclude complet efectele secundare în alte căi de cod; testați mai întâi pe un singur host și monitorizați înainte de implementare.
Pasul 1 – Efectuați o copie de rezervă a cheii „FeatureManagement Overrides” existente
# Creeaza folderul unde se va salva daca nu exista deja
New-Item -Path C:\Temp -ItemType Directory -Force | Out-Null# Exporta cheile in folder
reg export “HKLM\SYSTEM\CurrentControlSet\Control\FeatureManagement\Overrides” `
C:\Temp\FeatureOverrides-backup.reg
Dacă cheia nu există încă, exportul returnează o eroare, ceea ce este în regulă; înseamnă doar că, în prezent, nu este setat nicio suprascriere.
Pasul 2 – Aplicați suprascrierea
# Dezactivează indicatorul de funcționalitate 3802373433(care este calea de închidere defectuoasă)
New-Item -Path “HKLM:\SYSTEM\CurrentControlSet\Control\FeatureManagement\Overrides\4\3802373433” -ForceSet-ItemProperty `
-Path “HKLM:\SYSTEM\CurrentControlSet\Control\FeatureManagement\Overrides\4\3802373433” `
-Name “EnabledState” -Value 1 -Type DWordSet-ItemProperty `
-Path “HKLM:\SYSTEM\CurrentControlSet\Control\FeatureManagement\Overrides\4\3802373433” `
-Name “EnabledStateOptions” -Value 0 -Type DWord
Valoarea “4” din calea de acces funcționează în majoritatea mediilor. Dacă aveți deja alte intrări sub cheia „Overrides”, verificați fișierul .reg exportat la Pasul 1 pentru a confirma nivelul de prioritate utilizat de mediul dvs. înainte de a crea noua cheie.
Pasul 3 – Reporniți TermService
# Comanda de aici va deconecta sesiunile active!
Restart-Service -Name TermService -Force# Comanda de aici doar confirma starea serviciului
Get-Service -Name TermService | Select-Object Name, Status
Pasul 4 – Monitorizare
După aplicarea modificării, monitorizați ID-urile de eveniment 20498 și 6005 din EventViewer în următoarele 24–48 de ore, în special în momentul în care utilizatorii se deconectează. Dacă niciunul dintre aceste evenimente nu reapare și TermService rămâne în starea „Running”, înseamnă că modificarea este valabilă.
Dacă gazda se află deja într-o situație de blocaj, se recomandă revenirea la starea anterioară cu DISM
Dacă un host, sau masina, nu poate fi accesat deja prin RDP sau prin administrare la distanță, nu puteți aplica modificarea setărilor de la distanță. Mai întâi este necesară o resetare forțată, iar apoi actualizarea cumulativă din septembrie trebuie eliminată înainte ca blocajul să reapară.
Rețineți că comanda wusa /uninstall /kb:5122882 va eșua. Actualizările din septembrie sunt livrate sub formă de pachete combinate care includ atât actualizarea componentei de întreținere (SSU), cât și cea mai recentă actualizare cumulativă (LCU). Deoarece SSU nu poate fi eliminată, programul de instalare independent respinge întregul pachet. Utilizați în schimb DISM.
Găsiți numele pachetului:
dism.exe /Online /Get-Packages /Format:Table | findstr /i “Package_for_RollupFix”
Rezultatul așteptat:
Package_for_RollupFix~31bf3856ad364e35~amd64~~20348.5622.1.2 | Installed | Update | 9/9/2026
Eliminati pachetul:
dism.exe /Online /Remove-Package /PackageName:Package_for_RollupFix~31bf3856ad364e35~amd64~~20348.5622.1.2 /NoRestart
Înlocuiți numele pachetului cu șirul exact returnat de comanda anterioară. Componenta SSU va rămâne instalată după dezinstalare; acesta este comportamentul așteptat.
După ce gazda revine la funcționare, împiedicați reinstalarea automată a articolului KB. Dacă utilizați WSUS, respingeți articolul KB acolo. În caz contrar, aplicați o amânare a actualizării prin GPO pentru a împiedica Windows Update să îl instaleze din nou în timpul următoarei ferestre de întreținere.
Nota Bene:
Reintoarcerea prin DISM elimină toate patch-urile de securitate distribuite în ciclul din septembrie 2026, inclusiv patch-ul pentru CVE-2026-69525 (CVSS 9,8). Utilizați opțiunea de suprascriere a indicatorului de funcționalitate pe orice gazdă care este încă accesibilă. Rezervați revertarea pentru gazdele care sunt deja blocate și inaccesibile.
Actualizările cumulative din septembrie 2026 au provocat o adevărată încurcătură în mediile RDS. Însă revenirea la versiunea anterioară nu este soluția potrivită pentru serverele RDS expuse către internet, având în vedere vulnerabilitățile CVE pe care le remediază.
Încercați mai întâi să suprascrieți indicatorul de funcționalitate; această metodă menține remediile de securitate active și necesită doar o repornire a serviciului TermService. Microsoft investighează problema și, probabil, va lansa fie o remediere în afara ciclului obișnuit, fie îndrumări oficiale.
Leave A Comment?