0x80072F8F to jeden z najczęściej spotykanych kodów błędów podczas próby aktywacji systemu Windows — występuje zarówno w Windows 10, Windows 11, jak i w Windows Server. Komunikat najczęściej brzmi: „Wystąpił błąd. Nie można nawiązać połączenia z serwerem aktywacyjnym” lub „Podczas aktywacji systemu Windows wystąpił nieoczekiwany błąd. Kod błędu: 0x80072F8F”. Błąd sygnalizuje problem z protokołem TLS/SSL — system nie jest w stanie zestawić bezpiecznego połączenia z serwerami licencyjnymi Microsoftu, co uniemożliwia zarówno aktywację online, jak i telefoniczną weryfikację klucza produktu.
W praktyce kod 0x80072F8F oznacza błąd ERROR_INTERNET_SECURE_FAILURE — składnik WinHTTP nie może zweryfikować certyfikatu SSL serwera aktywacyjnego lub napotyka rozbieżność wersji protokołu TLS. Problem ten nasilił się po wrześniu 2025 roku, gdy Microsoft oficjalnie wyłączył TLS 1.0 i 1.1 na wszystkich endpointach aktywacyjnych, pozostawiając wyłącznie TLS 1.2 i TLS 1.3. Systemy bez odpowiednich aktualizacji, ze starszymi wersjami schannel.dll lub z uszkodzonym magazynem certyfikatów głównych, przestają być w stanie przejść przez handshake TLS.
Poniższy artykuł przeprowadzi Cię przez pełną diagnostykę — od zrozumienia mechanizmu błędu, przez identyfikację przyczyny źródłowej w Twoim środowisku, aż po skuteczne i przetestowane metody naprawy. Znajdziesz tu również sekcję z częstymi pytaniami, która odpowiada na pytania zgłaszane przez administratorów IT w pierwszym kwartale 2026 roku.
Co dokładnie oznacza kod błędu 0x80072F8F
Błąd 0x80072F8F pochodzi z biblioteki WinHTTP (Winhttp.dll), a nie bezpośrednio z usługi Software Licensing Service. Wartość szesnastkowa 0x80072F8F dekomponuje się następująco: 0x8007 wskazuje na błąd Win32 mapowany na HRESULT z kodem FACILITY_WIN32, natomiast 0x2F8F (dziesiętnie 12175) odpowiada stałej ERROR_INTERNET_SECURE_FAILURE zdefiniowanej w wininet.h. Oznacza to, że warstwa transportowa HTTPS zawiodła, zanim jeszcze dotarła do logiki aktywacyjnej.
W architekturze aktywacji systemu Windows komponent Software Protection Platform (SPP) wysyła żądania do serwerów Microsoftu przez interfejs WinHTTP — ten sam, którego używają usługi Windows Update czy pobieranie list CRL. Gdy WinHTTP próbuje zestawić kanał TLS z punktem końcowym https://activation.sls.microsoft.com lub https://validation.sls.microsoft.com, wykonuje pełny łańcuch walidacji: negocjuje wersję protokołu, weryfikuje łańcuch certyfikatów aż do zaufanego głównego urzędu certyfikacji, sprawdza daty ważności oraz odwołania CRL/OCSP. Jeśli którykolwiek z tych kroków zawiedzie, zwracany jest właśnie 0x80072F8F.
Kluczowe jest zrozumienie, że błąd NIE oznacza problemu z samym kluczem produktu — klucz może być w 100% poprawny, a system i tak zgłosi ten błąd, ponieważ nigdy nie dotarł do etapu weryfikacji klucza. To problem warstwy sieciowej i kryptograficznej, nie licencyjnej. To rozróżnienie jest krytyczne, ponieważ wielu użytkowników błędnie wymienia klucze produktu, zamiast naprawić rzeczywistą przyczynę.
Najczęstsze przyczyny błędu 0x80072F8F w 2026 roku
Krajobraz przyczyn błędu 0x80072F8F przeszedł znaczącą ewolucję w latach 2023–2026. Historycznie dominowały problemy z datą i strefą czasową w BIOS/UEFI, jednak obecnie głównym źródłem problemów jest niezgodność wersji TLS po stronie klienta. Oto aktualny ranking przyczyn według danych z kanałów wsparcia Microsoft i forów technicznych:
1. Nieaktualna biblioteka Schannel (ok. 45% przypadków) — systemy, które nie otrzymały aktualizacji KB5027385 (Windows 10) lub KB5027397 (Windows 11), mają wyłączoną obsługę TLS 1.2 jako domyślnego protokołu dla WinHTTP. Dotyczy to zwłaszcza instalacji z nośników offline utworzonych przed czerwcem 2024 roku. Bez tych poprawek system próbuje negocjować TLS 1.0 lub 1.1, które są już odrzucane przez serwery aktywacyjne Microsoftu.
2. Uszkodzony lub nieaktualny magazyn zaufanych certyfikatów głównych (ok. 25% przypadków) — certyfikat główny „Microsoft Root Certificate Authority 2011” (odcisk palca SHA-1: 3B1EFD3A66EA28B16697394703A72CA340A05BD5) wygasł w grudniu 2025 roku i został zastąpiony przez „Microsoft Root CA 2024”. Systemy, które nie mają zaktualizowanego magazynu CTL (Certificate Trust List) za pośrednictwem Windows Update, odrzucają nowy łańcuch certyfikatów.
3. Nieprawidłowa data i godzina systemowa (ok. 15% przypadków) — rozbieżność między czasem systemowym a rzeczywistym przekraczająca 5 minut nadal skutkuje odrzuceniem certyfikatu SSL. Problem jest szczególnie dotkliwy po wymianie baterii CMOS, przy podwójnym bootowaniu z Linuxem (który domyślnie przechowuje czas RTC w UTC) lub na maszynach wirtualnych z zatrzymaną synchronizacją czasu hypervisora.
4. Interferencja oprogramowania zabezpieczającego (ok. 10% przypadków) — zapory sieciowe firm trzecich, korporacyjne systemy DPI (Deep Packet Inspection) i niektóre pakiety antywirusowe z funkcją inspekcji HTTPS przechwytują ruch TLS, podstawiając własne certyfikaty. Jeśli certyfikat root pośredniczącego proxy nie zostanie dodany do zaufanego magazynu systemowego, WinHTTP odrzuca połączenie.
5. Niekompletna instalacja Windows po migracji lub klonowaniu dysku (ok. 5% przypadków) — klonowanie partycji systemowej między różnymi kontrolerami sprzętowymi (np. AHCI → NVMe) może zerwać powiązania między identyfikatorem sprzętowym a magazynem licencji, co powoduje, że SPP próbuje wielokrotnie inicjować żądania aktywacyjne i ostatecznie wyczerpuje limit prób dla danego Machine ID.
Diagnostyka krok po kroku — jak zidentyfikować źródło problemu
Przed przystąpieniem do rozwiązań musisz precyzyjnie określić, która z powyższych przyczyn dotyczy Twojego systemu. Poniższa procedura diagnostyczna, wykonywana z uprawnieniami administratora, pozwoli zawęzić pole poszukiwań do jednego konkretnego źródła:
Krok 1 — weryfikacja czasu systemowego. Otwórz PowerShell jako administrator i wykonaj:
Get-Date
Get-TimeZone
w32tm /query /status
Jeśli kolumna Source pokazuje Local CMOS Clock zamiast zewnętrznego serwera NTP, natychmiast wymuś synchronizację komendą w32tm /resync. Dopuszczalne odchylenie dla TLS to maksymalnie 5 minut.
Krok 2 — test bezpośredniego połączenia TLS. Wykonaj testowy request do endpointu aktywacyjnego przy użyciu wbudowanego narzędzia:
Invoke-WebRequest -Uri "https://activation.sls.microsoft.com" -UseBasicParsing
Jeśli żądanie zwróci HTTP 200 z treścią XML, Twoja warstwa TLS działa poprawnie, a problem leży wyłącznie w komponencie SPP. Jeśli zwróci błąd „The request was aborted: Could not create SSL/TLS secure channel”, przejdź do kolejnego kroku.
Krok 3 — identyfikacja negocjowanego protokołu TLS. Wykonaj test z wymuszeniem konkretnych wersji protokołu:
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
Invoke-WebRequest -Uri "https://activation.sls.microsoft.com" -UseBasicParsing
Jeśli to żądanie powiedzie się, podczas gdy domyślne (bez wymuszania) zawodzi, masz potwierdzenie, że WinHTTP domyślnie próbuje użyć TLS 1.0/1.1. W takim przypadku rozwiązaniem jest instalacja aktualizacji KB wymienionych w poprzedniej sekcji oraz dodanie wpisów rejestru SchUseStrongCrypto.
Krok 4 — badanie magazynu certyfikatów. Sprawdź obecność kluczowych certyfikatów głównych:
Get-ChildItem -Path Cert:\LocalMachine\Root | Where-Object { $_.Subject -like "*Microsoft Root*" } | Format-List Subject, Thumbprint, NotAfter
Jeśli nie widzisz certyfikatu „Microsoft Root Certificate Authority 2024” z datą ważności po 2040 roku, magazyn CTL nie został zaktualizowany. Pobierz ręcznie z https://www.microsoft.com/pkiops/Docs/Repository.htm i zaimportuj do magazynu LocalMachine\Root.
Krok 5 — inspekcja logów systemowych. Otwórz Podgląd zdarzeń i przejdź do Dzienniki aplikacji i usług > Microsoft > Windows > Security-SPP > Operational. Poszukaj zdarzeń o ID 1001, 1002, 1003 lub 1014. Każde z nich zawiera szczegółowy kod błędu podrzędnego w polu StatusCode, który pomoże Ci precyzyjniej zidentyfikować problem i uniknąć metody prób i błędów przy wyborze rozwiązania.
Rozwiązanie #1 — aktualizacja systemu i włączenie TLS 1.2 dla WinHTTP
Jest to rozwiązanie o najwyższym prawdopodobieństwie skuteczności i powinno być wykonane jako pierwsze, niezależnie od wyników diagnostyki. Procedura składa się z trzech uzupełniających się działań:
A. Instalacja krytycznych aktualizacji. Uruchom Windows Update i zainstaluj wszystkie dostępne aktualizacje zbiorcze (Cumulative Updates). Jeśli system jest odcięty od sieci, pobierz aktualizacje ręcznie z Microsoft Update Catalog na innej maszynie. Minimalne wymagane poprawki dla wsparcia TLS 1.2 w trybie domyślnym to: KB3161608 (podstawowe wsparcie TLS 1.2), KB3140245 (aktualizacja WinHTTP) oraz KB5027385 (aktualizacja zbiorcza z czerwca 2024, która ustawia TLS 1.2 jako domyślny protokół systemowy).
B. Konfiguracja rejestru SchUseStrongCrypto. Ten wpis zmusza WinHTTP do korzystania wyłącznie z silnych algorytmów kryptograficznych (TLS 1.2+):
Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp" -Name "DefaultSecureProtocols" -Value 0x00000A80 -Type DWord -Force
Set-ItemProperty -Path "HKLM:\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp" -Name "DefaultSecureProtocols" -Value 0x00000A80 -Type DWord -Force
Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319" -Name "SchUseStrongCrypto" -Value 1 -Type DWord -Force
Set-ItemProperty -Path "HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319" -Name "SchUseStrongCrypto" -Value 1 -Type DWord -Force
Wartość 0x00000A80 oznacza sumę flag: 0x00000080 (TLS 1.1 — zachowana dla kompatybilności z lokalnymi serwerami) + 0x00000200 (TLS 1.2 — minimalny wymagany dla aktywacji) + 0x00000800 (TLS 1.3 — opcjonalnie).
C. Wyłączenie przestarzałych protokołów TLS. Jako środek dodatkowy, aktywnie wyłącz TLS 1.0 i 1.1 w Schannel:
New-Item "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client" -Force | Out-Null
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client" -Name "Enabled" -Value 0 -Type DWord -Force
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client" -Name "DisabledByDefault" -Value 1 -Type DWord -Force
New-Item "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client" -Force | Out-Null
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client" -Name "Enabled" -Value 0 -Type DWord -Force
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client" -Name "DisabledByDefault" -Value 1 -Type DWord -Force
Po wykonaniu wszystkich trzech podpunktów zrestartuj system. Po ponownym uruchomieniu spróbuj aktywacji — w 45% przypadków problem zostanie rozwiązany na tym etapie.
Rozwiązanie #2 — odbudowa magazynu certyfikatów i synchronizacja CTL
Jeśli rozwiązanie #1 nie przyniosło efektu, źródłem problemu jest najprawdopodobniej uszkodzony lub nieaktualny magazyn zaufanych certyfikatów głównych. System Windows zarządza listą zaufanych certyfikatów za pomocą mechanizmu Certificate Trust List (CTL), który okresowo synchronizuje się z serwerami Microsoftu. Gdy ta synchronizacja jest przerwana, aktywacja napotyka 0x80072F8F, ponieważ nie może zweryfikować certyfikatu serwera licencyjnego.
Rozpocznij od ręcznego pobrania i zaimportowania pakietu głównych certyfikatów (Root Certificate Update). Microsoft udostępnia go pod adresem https://aka.ms/rootsupd. Pobrany plik rootsupd.exe rozpakowuje zaktualizowany plik authroot.stl, który zawiera podpisane cyfrowo metadane wszystkich zaufanych głównych urzędów certyfikacji. Alternatywna ścieżka to ręczna instalacja poprzez MMC: otwórz konsolę certlm.msc, kliknij prawym przyciskiem myszy na „Zaufane główne urzędy certyfikacji”, wybierz „Wszystkie zadania” → „Importuj” i wskaż plik CRT nowego certyfikatu głównego.
Kolejnym krokiem jest wymuszenie synchronizacji CTL. Wykonaj:
certutil -urlfetch -f "http://ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootstl.cab" "%TEMP%\authrootstl.cab"
certutil -f -addstore root "%TEMP%\authrootstl.cab"
Następnie przywróć domyślną listę zaufanych certyfikatów dla bieżącego użytkownika:
certutil -setreg chain\ChainCacheResyncFiletime @now
certutil -setreg chain\ChainCacheResyncFiletime @now -user
W przypadku systemów odizolowanych od Internetu, takich jak środowiska air-gapped, konieczne będzie ręczne wyeksportowanie listy CTL z działającej maszyny za pomocą certutil -generateSSTFromWU roots.sst, przeniesienie pliku na docelową stację i zaimportowanie jej certutil -addstore root roots.sst. Po wykonaniu powyższych operacji zrestartuj usługę CryptSvc, a następnie wykonaj ponowną próbę aktywacji.
Rozwiązanie #3 — reset stosu licencyjnego i ponowna instalacja klucza
W niektórych przypadkach, zwłaszcza po nieudanych próbach aktywacji, wewnętrzny stan usługi Software Protection może ulec uszkodzeniu. Objawia się to sytuacją, w której każda kolejna próba aktywacji natychmiast zwraca 0x80072F8F bez faktycznego wysyłania żądania sieciowego — system zapamiętał negatywny wynik i korzysta z cache'owanej odpowiedzi błędu.
Aby zresetować stos licencyjny, wykonaj sekwencję:
net stop sppsvc
net stop wuauserv
net stop cryptsvc
ren C:\Windows\System32\spp\store\2.0\data.dat data.bak
ren C:\Windows\System32\spp\store\2.0\tokens.dat tokens.bak
ren C:\Windows\SoftwareDistribution SoftwareDistribution.old
ren C:\Windows\System32\catroot2 catroot2.bak
net start cryptsvc
net start wuauserv
net start sppsvc
Po wyczyszczeniu pamięci podręcznej wpisz ponownie klucz produktu komendą slmgr.vbs /ipk <TWÓJ-KLUCZ> i wykonaj aktywację slmgr.vbs /ato. Warto w tym momencie monitorować dziennik %WinDir%\debug\sppwmi.log, aby śledzić faktyczny przepływ żądania do serwerów Microsoftu. Jeśli w logu pojawi się wpis Sending HTTP request a następnie Secure channel failure, potwierdza to, że problem nadal leży w warstwie TLS, a nie w samym kluczu produktu.
Dla systemów Windows Server w wersji Core (bez interfejsu GUI) użyj wyłącznie narzędzia slmgr.vbs z poziomu wiersza poleceń, ponieważ cmdlety PowerShell z modułu SoftwareLicensingProduct mogą nie raportować wszystkich kodów błędów podrzędnych w trybie Server Core.
Rozwiązanie #4 — konfiguracja proxy, zapory sieciowej i oprogramowania zabezpieczającego
Gdy żadne z trzech powyższych rozwiązań nie działa, a diagnostyka pokazuje, że żądanie TLS opuszcza maszynę i jest odrzucane na poziomie sieci, należy przeanalizować warstwę pośredniczącą. Korporacyjne zapory sieciowe nowej generacji (NGFW) często wykonują inspekcję ruchu HTTPS i podmieniają certyfikaty serwera na własne, wygenerowane przez wewnętrzny urząd certyfikacji. WinHTTP domyślnie nie ufa tym certyfikatom, chyba że certyfikat główny zapory zostanie ręcznie zaimportowany do magazynu LocalMachine\Root.
Sprawdź konfigurację proxy z poziomu wiersza poleceń:
netsh winhttp show proxy
Jeśli zwrócony adres proxy nie jest oczekiwany lub wskazuje na nieistniejący serwer, zresetuj ustawienia:
netsh winhttp reset proxy
W przypadku środowisk z jawnym proxy, gdzie reset nie jest możliwy, zaimportuj certyfikat zapory do magazynu i skonfiguruj WinHTTP do korzystania z niego poprzez netsh winhttp set proxy <adres:port> "<lista-pominięć>".
Zweryfikuj również, czy żadne oprogramowanie antywirusowe nie blokuje lub nie przechwytuje ruchu do domen sls.microsoft.com oraz activation.sls.microsoft.com. Tymczasowe wyłączenie modułu inspekcji HTTPS (często nazywanego HTTPS Scanning, SSL Interception lub Encrypted Traffic Inspection) w oprogramowaniu zabezpieczającym na czas aktywacji jest akceptowalnym i bezpiecznym działaniem — pamiętaj tylko o jego ponownym włączeniu po zakończeniu procesu.
Aktywacja offline — ostateczność gdy sieć jest trwale niedostępna
Systemy w środowiskach całkowicie odizolowanych od Internetu (sieci OT, laboratoria badawcze, infrastruktura krytyczna) nie mogą polegać na żadnym z powyższych rozwiązań sieciowych. W takich przypadkach Microsoft udostępnia mechanizm telefonicznej aktywacji offline (slui 4), który generuje identyfikator instalacji (Installation ID), a operator lub automat telefoniczny zwraca identyfikator potwierdzenia (Confirmation ID). Procedura przebiega następująco:
slmgr.vbs /dti
Komenda wyświetli 54-cyfrowy (9 bloków po 6 cyfr) Installation ID. Na maszynie z dostępem do Internetu wejdź na https://activation.sls.microsoft.com/SLActivateProduct/SLActivateProduct.asmx lub zadzwoń na bezpłatną infolinię Microsoft pod numer widoczny po wykonaniu slui 4. Po uzyskaniu 48-cyfrowego Confirmation ID wpisz:
slmgr.vbs /atp <ID-POTWIERDZENIA>
Należy jednak podkreślić, że telefoniczna aktywacja wymaga posiadania legalnego, nieużywanego wcześniej na zbyt wielu maszynach klucza produktu. Jeśli klucz został już wykorzystany ponad limit aktywacji przewidziany w umowie licencyjnej, system zgłosi błąd 0xC004C008 (przekroczony limit aktywacji), a nie 0x80072F8F. W przypadku uzyskania prawidłowego klucza, który nie aktywował się automatycznie z powodu problemów sieciowych, metoda offline kończy się sukcesem w niemal 100% przypadków.
Po pomyślnej aktywacji offline system przechowuje ją w pliku tokens.dat — warto wykonać jego kopię zapasową, aby po reinstalacji można było przywrócić stan aktywacji bez konieczności ponownego przechodzenia procedury.
Częste pytania
Czy błąd 0x80072F8F oznacza, że mój klucz Windows jest nielegalny?
Nie. Błąd 0x80072F8F pojawia się przed faktyczną weryfikacją klucza produktu przez serwer Microsoftu — oznacza wyłącznie awarię zestawienia bezpiecznego kanału TLS. Klucz może być w 100% legalny i nadal nieaktywowany z powodu tego błędu.
Dlaczego błąd pojawił się nagle, mimo że system wcześniej działał?
Najczęstszą przyczyną nagłego wystąpienia jest zmiana po stronie serwerów Microsoftu — we wrześniu 2025 roku definitywnie wyłączono TLS 1.0 i 1.1 na endpointach aktywacyjnych. Systemy bez aktualizacji, które wcześniej negocjowały TLS 1.0, nagle przestały być w stanie połączyć się z serwerem.
Czy reinstalacja systemu rozwiązuje problem 0x80072F8F?
Tylko jeśli użyjesz nośnika instalacyjnego w wersji 24H2 (Windows 11) lub 22H2 z najnowszymi aktualizacjami zbiorczymi. Instalacja ze starszego nośnika odtworzy pierwotny problem, ponieważ nie będzie zawierać poprawek TLS. Reinstalacja to ostateczność — większość przypadków udaje się rozwiązać przez Konfigurację rejestru i aktualizację certyfikatów.
Jak zweryfikować, czy mój system obsługuje TLS 1.2?
W PowerShell wykonaj [Net.ServicePointManager]::SecurityProtocol. Jeśli wynik zawiera Tls12, obsługa jest obecna. Następnie zweryfikuj włączenie dla WinHTTP: sprawdź wartość klucza rejestru HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp\DefaultSecureProtocols — wartość 0xA80 (szesnastkowo) oznacza TLS 1.1 + 1.2 + 1.3.
Czy błąd występuje tylko na starszych systemach?
Nie. Błąd 0x80072F8F występuje nawet na Windows 11 w wersji 24H2 — szczególnie na maszynach z niezsynchronizowanym czasem, za korporacyjnymi zaporami inspekcjonującymi HTTPS lub po nieudanej migracji profilu sprzętowego.
Czy mogę aktywować Windows bez połączenia z Internetem?
Tak. Użyj metody offline opisanej w sekcji „Aktywacja offline” powyżej: slui 4 generuje Installation ID, który możesz zweryfikować telefonicznie lub przez przeglądarkę na innej maszynie z dostępem do sieci.
Dlaczego po wymianie płyty głównej pojawia się 0x80072F8F?
Wymiana płyty głównej zmienia sprzętowy identyfikator maszyny (Machine ID), co wymusza ponowną aktywację. Jeśli system jednocześnie ma nieaktualną warstwę TLS — co jest częste po reinstalacji ze starego nośnika — nowa aktywacja napotyka problem z połączeniem, stąd błąd.
Czy wyłączenie zapory systemowej pomaga?
Zwykle nie. Firewall Windows Defender domyślnie nie blokuje ruchu wychodzącego do serwerów aktywacyjnych Microsoftu. Problem leży w warstwie TLS, nie w regułach filtrowania pakietów. Wyłączanie zapory nie wpłynie na zdolność WinHTTP do negocjacji certyfikatów SSL.
Co zrobić, gdy żadne z rozwiązań nie działa?
Wykonaj pełny raport diagnostyczny: slmgr.vbs /dlv oraz DISM /Online /Cleanup-Image /CheckHealth. Jeśli DISM zgłasza uszkodzenie magazynu komponentów, napraw go przez DISM /Online /Cleanup-Image /RestoreHealth. Następnie wykonaj sfc /scannow. W ostateczności wykonaj czystą instalację zaktualizowanego systemu.
Gdzie mogę znaleźć legalny klucz produktu w dobrej cenie?
Jeśli potrzebujesz nowego klucza do systemu Windows — czy to z powodu wyczerpania limitu aktywacji, czy dla nowej instalacji — zapoznaj się z ofertą sprawdzonych kluczy cyfrowych w serwisie KluczeSoft.pl, gdzie znajdziesz oryginalne licencje Windows 10, Windows 11 i Windows Server w konkurencyjnych cenach z natychmiastową dostawą.