Jak sprawdzić historię Windows Update i znaleźć nieudany pakiet
Spis treści

Gdy Windows zgłasza nieudaną aktualizację, warto ustalić, co dokładnie nie zadziałało: pobieranie, przygotowanie, instalacja czy ponowne uruchomienie. Log Windows Update pomaga wskazać pakiet i etap awarii. „Log” nie oznacza jednak jednego pliku ani długiego tekstu, który trzeba ręcznie rozszyfrować. W większości typowych przypadków wystarczy zacząć od historii aktualizacji w Ustawieniach i zapisać kilka dokładnych danych.

Nie czyść dzienników ani nie uruchamiaj poleceń, zanim zapiszesz komunikat o błędzie. Jeśli komputer pokazuje pełnoekranową instalację lub cofanie zmian, nie przerywaj tego procesu, żeby szukać logów. Gdy pulpit będzie ponownie dostępny, wykonaj poniższe kroki.

Historia aktualizacji to pierwsze miejsce do sprawdzenia

W Windows 11 otwórz Ustawienia → Windows Update → Historia aktualizacji. W Windows 10 sekcja może nazywać się Wyświetl historię aktualizacji w ustawieniach „Aktualizacja i zabezpieczenia”. Znajdź pozycję oznaczoną jako nieudana. Zapisz nazwę, datę, typ aktualizacji, numer KB oraz kod, jeśli system go wyświetla.

Jeśli widzisz kilka nieudanych wpisów, sprawdź, czy powtarza się ten sam numer KB. To ważniejsze niż sama liczba prób: różne pakiety mogą kończyć się różnymi błędami. Ustal też, na którym etapie pojawia się problem. Przy błędzie pobierania sprawdza się sieć i dostępność pakietu. Gdy pliki pobrały się, ale instalacja nie doszła do końca, bardziej przydatne są kod, wolne miejsce, zgodność sterowników i logi obsługi systemu.

Historia jest krótkim podsumowaniem, a nie pełnym zapisem diagnostycznym. Często zawiera jednak informacje wystarczające do następnego kroku. Przy analizie kodu skorzystaj z poradnika jak rozpoznać przyczynę błędu po kodzie Windows Update. Jeśli po restarcie Windows automatycznie cofnął instalację, przeczytaj osobno dlaczego aktualizacja jest cofana po ponownym uruchomieniu.

Kiedy potrzebny jest szczegółowy WindowsUpdate.log

W nowszych wersjach Windows log usługi jest tworzony jako ślady ETW w plikach .etl, a nie jako jeden stale czytelny plik tekstowy. Microsoft udostępnia polecenie PowerShell Get-WindowsUpdateLog, które łączy i konwertuje te pliki ETL do statycznego WindowsUpdate.log. Przydaje się to w dokładniejszej diagnostyce — na przykład gdy problem się powtarza, krótki kod nie wyjaśnia przyczyny albo serwis poprosił o plik.

Jeśli swobodnie korzystasz z PowerShell, otwórz go w zwykły sposób i uruchom Get-WindowsUpdateLog. Parametry i wymagania mogą zależeć od wersji Windows oraz środowiska. Według dokumentacji Microsoft polecenie domyślnie zapisuje czytelną kopię na pulpicie bieżącego użytkownika. To utworzenie raportu, a nie zmiana ustawień Windows Update. Jeśli pojawi się błąd, nie pobieraj przypadkowego modułu ani skryptu z nieznanej strony.

Oficjalny opis i dodatkowe parametry znajdziesz w dokumentacji Microsoft Learn dotyczącej Get-WindowsUpdateLog. Jeśli potrzebujesz tylko kodu błędu, uruchamianie PowerShell zwykle nie jest konieczne.

Inne logi i ich przeznaczenie

Przy niektórych awariach bardziej przydatny niż ogólny WindowsUpdate.log jest log składnika, który uczestniczył w instalacji. Na przykład CBS.log w %systemroot%LogsCBS zawiera informacje o obsłudze składników Windows. Ślady ETL usługi Update Orchestrator pomagają analizować sytuacje, w których aktualizacja jest dostępna, ale nie rozpoczyna się pobieranie lub instalacja albo po instalacji nie uruchamia się restart. To pliki diagnostyczne dotyczące określonego etapu, a nie lista wszystkich zainstalowanych aktualizacji.

Plików .etl nie należy czytać zwykłym edytorem tekstu. Nie edytuj ich ani nie usuwaj — oryginalne wpisy mogą być potrzebne do analizy. Dokumentacja Microsoft dotycząca logów Windows Update opisuje lokalizację i zastosowanie podstawowych plików, w tym CBS.log i śladów aktualizacji.

Praktyczna kolejność dla użytkownika jest prosta: najpierw historia w Ustawieniach, później odpowiednie narzędzie do rozwiązywania problemów, a dopiero potem szczegółowy log, jeśli jest potrzebny. Nie ma powodu przeglądać każdego pliku systemowego „na wszelki wypadek”.

Jak znaleźć przydatne wpisy bez pochopnych wniosków

Po otwarciu tekstowego WindowsUpdate.log znajdź datę i godzinę nieudanej próby, a następnie porównaj je z historią aktualizacji. Sprawdź, czy log wspomina właściwy pakiet, kod zakończenia lub składnik. Znaczniki czasu pomagają odróżnić stare wpisy od bieżącej próby. Nie wyciągaj wniosków tylko ze słów Error albo Failed: duży log może zawierać wpisy o ponawianych czynnościach, które nie są ostateczną przyczyną.

Jeśli wpis jest niezrozumiały, zachowaj oryginalny plik i przekaż specjaliście fragment z okolic czasu awarii, kod, numer KB oraz wersję Windows. Nie publikuj całego logu na otwartym forum bez sprawdzenia, czy nie zawiera danych osobistych lub służbowych. Nie zmieniaj treści pliku przed przekazaniem, bo utracisz kontekst.

Polecenie Get-WindowsUpdateLog tworzy tekstową kopię śladów ETL, ale samo nie naprawia aktualizacji ani nie dowodzi usterki sprzętu. Jeśli błąd wskazuje na składniki systemu, dalsze kroki zależą od kodu; ogólny plan przed czystą instalacją opisuje poradnik jak naprawić błąd kończenia aktualizacji Windows.

Jeśli historia nie pokazuje czytelnego kodu

Sprawdź dokładną nazwę pakietu i jego status. Czasem aktualizacja nie pojawia się w historii jako nieudana, choć nadal czeka na restart lub komunikat jest wyświetlony w innym miejscu. Zapisz zrzut ekranu komunikatu, wersję Windows i godzinę zdarzenia. Podgląd zdarzeń otwieraj dopiero wtedy, gdy trzeba rozszerzyć diagnostykę lub zaleciło to wsparcie. W dzienniku Windows → Setup mogą znajdować się wpisy instalacji, ale ich nazwy i znaczenie zależą od sytuacji.

Nie dobieraj rozwiązania na podstawie przypadkowego dopasowania identyfikatora zdarzenia do wyniku wyszukiwania. Wpis może mieć charakter informacyjny, a nie wskazywać przyczyny awarii. Porównuj czas zdarzenia, pakiet, kod i działanie Windows. W razie wątpliwości lepiej przekazać dane specjaliście niż zmieniać usługi lub rejestr na podstawie numeru zdarzenia.

Jak przekazać dane do serwisu

Przygotuj krótki zestaw informacji:

  • wersję i edycję Windows;
  • nazwę i numer KB nieudanego pakietu;
  • dokładny kod i treść komunikatu;
  • datę i przybliżoną godzinę awarii;
  • etap, na którym pojawia się błąd;
  • wykonane kontrole i informację, czy wynik się powtarza;
  • plik WindowsUpdate.log lub odpowiedni fragment, jeśli został zamówiony.

Taki opis jest bardziej użyteczny niż „aktualizacja nie działa”. Jeśli problemowi towarzyszą zawieszenia, znikający dysk, błędy odczytu albo niebieski ekran, wspomnij o tym — potrzebna może być kontrola wykraczająca poza Windows Update. W razie potrzeby skorzystaj z diagnostyki komputera i nie uruchamiaj wielu kolejnych prób instalacji.

Częste pomyłki

  • Mylenie historii aktualizacji z logiem technicznym.Historia pokazuje krótki status; WindowsUpdate.log i CBS.log zawierają szczegółowe dane diagnostyczne.
  • Otwieranie ETL jak zwykłego tekstu.Najpierw trzeba je przekonwertować odpowiednim narzędziem; nie edytuj oryginałów.
  • Uznawanie każdego wpisu Error za przyczynę.Liczą się kontekst, czas i kod zakończenia.
  • Czyszczenie logów przed kontaktem z pomocą.Najpierw zachowaj dane, które mogą pomóc odtworzyć problem.
  • Publikowanie pełnego logu bez sprawdzenia.Plik może zawierać informacje o urządzeniu lub środowisku pracy.

W skrócie

Do pierwszej kontroli wystarczy historia Windows Update: znajdź pakiet, datę, KB i kod. Szczegółowy WindowsUpdate.log utwórz poleceniem Get-WindowsUpdateLog, gdy potrzebna jest dokładniejsza analiza lub prosi o niego serwis. ETL i CBS pomagają badać wybrane etapy, ale same nie są instrukcją naprawy. Zachowaj pierwotne informacje, porównaj je z czasem awarii i dopiero potem wybierz kolejny krok.

Oficjalne źródła