Historia awarii Windows: jak znaleźć zdarzenia związane z problemem

Historia błędów Windows jest przydatna, gdy po awarii komputer znów działa i trudno odtworzyć, co się stało. Najpierw zapisz godzinę oraz objaw, a potem wybierz właściwy widok. Monitor niezawodności porządkuje zdarzenia na osi czasu, natomiast Podgląd zdarzeń pokazuje szczegółowe komunikaty źródeł. Żaden z nich nie jest listą części do wymiany.

Zacznij od zdarzenia, które chcesz wyjaśnić

Przed otwarciem narzędzi zanotuj, czy zawiesiła się jedna aplikacja, komputer zrestartował się, zniknął dysk czy przestała działać sieć. Zapisz przybliżoną godzinę, wykonywaną czynność i ostatnią istotną zmianę. Jeżeli ręcznie wymusiłeś wyłączenie po zawieszeniu, odnotuj oba momenty. Błąd zapisany po starcie może opisywać przerwanie pracy, a nie pierwotne zawieszenie.

Nie rozpoczynaj od przeglądania całego miesiąca czerwonych ikon. Windows może rejestrować nieudane, ponawiane działania, których skutków nie zauważasz. Znaczenie wpisu wynika z jego treści i zgodności z objawem. Rozpoznawalny wzorzec przy każdej awarii jest silniejszą wskazówką niż liczba błędów w ogólnym zestawieniu.

Monitor niezawodności: dzień, godzina i szczegóły

Wyszukaj „Wyświetl historię niezawodności” w menu Start. Alternatywnie w oknie Uruchom otwieranym przez Win + R wpisz:

perfmon /rel

Wybierz odpowiedni dzień, a następnie pozycję z listy zdarzeń. Otwórz szczegóły techniczne awarii. Sprawdź nazwę programu, moment zdarzenia, typ problemu i dostępny kod. W tej samej osi mogą być widoczne także instalacje i aktualizacje, które pomagają znaleźć punkt zmiany. Ich bliskość czasowa jest tropem, a nie ostatecznym dowodem winy.

Przy awarii aplikacji zapisz nazwę pliku wykonywalnego, moduł wskazany w raporcie i kod wyjątku. Nie pobieraj pojedynczej biblioteki DLL z przypadkowej strony tylko dlatego, że występuje w polu modułu. Wskazana biblioteka może być miejscem ujawnienia problemu, a nie jego pierwotnym źródłem. Potrzebny jest kontekst wersji programu i sposobu odtworzenia awarii.

Ogólny komunikat o niepoprawnym zamknięciu Windows nie oznacza, że system sam zainicjował wyłączenie. Może dotyczyć odcięcia zasilania albo Twojej reakcji na zawieszenie. Porównaj go z notatką. Do restartów przyda się szerszy poradnik gdzie szukać przyczyny samoczynnego restartu.

Podgląd zdarzeń: zawęź dziennik i czas

Wyszukaj Podgląd zdarzeń lub uruchom:

eventvwr.msc

W Dziennikach systemu Windows zacznij od „Aplikacja” przy awarii programu i „System” przy problemie urządzenia lub całego komputera. Użyj filtrowania bieżącego dziennika, aby ograniczyć czas do okolicy zdarzenia. Zachowaj również komunikaty informacyjne, jeśli opisują start, zatrzymanie lub wcześniejszy etap operacji. Sam filtr błędów może ukryć potrzebny kontekst.

Kliknij pozycję i przeczytaj kartę Ogólne, a w razie potrzeby Szczegóły. Zapisz źródło, identyfikator zdarzenia, godzinę oraz właściwy komunikat. Numer bez źródła jest niepełną informacją: nie służy jako uniwersalny kod usterki wszystkich elementów Windows. Wyszukuj dokumentację konkretnego źródła i pasującej wersji systemu.

Skutek często pojawia się później niż przyczyna

Zdarzenie Kernel-Power 41 informuje, że poprzednia praca nie zakończyła się prawidłowo. Samo nie rozstrzyga, czy winny był zasilacz, błąd systemu, zawieszenie czy wymuszone wyłączenie. Podobnie nieudany start aplikacji po restarcie może być konsekwencją przerwanego zapisu. Cofnij się do wcześniejszych komunikatów i sprawdź, czy opisują pierwszy etap.

Brak użytecznego wpisu również nie wyklucza usterki. Komputer mógł stracić możliwość zapisania dziennika lub zrzutu, a dany program może prowadzić własne logi. Długotrwały problem sprzętowy nie musi zostać w pełni opisany przez Windows. Połącz historię z obserwacją, zamiast oczekiwać od dziennika gotowej diagnozy.

Zachowaj fragment do porównania lub konsultacji

Jeżeli szukasz awarii sprzed kilku tygodni, sprawdź, czy dziennik nadal obejmuje ten okres. Starsze wpisy mogą zostać zastąpione po osiągnięciu skonfigurowanego rozmiaru logu. Pusty fragment historii nie jest potwierdzeniem, że komputer działał wtedy poprawnie. Przy kolejnym wystąpieniu zapisz potrzebny zakres od razu, gdy szczegóły są dostępne.

Przykładowo aplikacja zamyka się o 14:03, a Ty restartujesz komputer o 14:08, żeby wrócić do pracy. Komunikat dotyczący rozruchu i poprzedniego zamknięcia opisuje późniejszy etap. Najpierw znajdź raport aplikacji z 14:03, sprawdź jej wersję i czynność wykonywaną tuż przed zamknięciem. Takie rozdzielenie momentów zapobiega łączeniu każdej awarii programu z ogólnym błędem zasilania.

Możesz skopiować treść wybranej pozycji albo zapisać odpowiednie zdarzenia do pliku EVTX funkcją Podglądu zdarzeń. Wybierz wąski zakres potrzebny do wyjaśnienia problemu. Przed udostępnieniem sprawdź nazwy użytkowników, ścieżki, adresy i inne informacje o komputerze. Nie publikuj bez potrzeby całych dzienników i plików zrzutu pamięci.

Nie czyść historii przed diagnozą. Po poprawce przyda się do sprawdzenia, czy dawny wzorzec powraca. Zachowaj także informację, co zmieniłeś: wersję sterownika, konfigurację lub program. Jeśli po kolejnym wystąpieniu masz to samo źródło i podobną sekwencję komunikatów, porównanie będzie dużo łatwiejsze.

Wybierz działanie na podstawie treści

Błąd jednej aplikacji kieruje do jej aktualizacji, dodatków i konfiguracji; błąd zapisu wymaga sprawdzenia wskazanego nośnika oraz dostępności danych. Nie uruchamiaj automatycznie SFC i DISM po każdej czerwonej ikonie. Narzędzia składników systemowych nie naprawią przerwanego przewodu ani błędu programu tylko dlatego, że odnotował go Windows.

Po wykonaniu jednej uzasadnionej zmiany powtórz zwykłą czynność i sprawdź, czy objaw oraz odpowiadający mu wzorzec zniknęły. Jeśli program przestał uruchamiać się po aktualizacji, wykorzystaj poradnik o naprawie aplikacji po zmianie wersji. Ostatecznym kryterium jest poprawne działanie, a nie całkowicie pusty dziennik.