Dlaczego niespodziewane restarty są groźniejsze niż zwykłe zawieszki
Restart bez komunikatu vs klasyczny niebieski ekran (BSOD)
Kiedy komputer sam się restartuje bez żadnego komunikatu, sytuacja jest trudniejsza diagnostycznie niż klasyczny niebieski ekran (BSOD). BSOD zatrzymuje system, wyświetla kod błędu, nazwę sterownika lub modułu oraz często informuje, że system utworzył zrzut pamięci. To konkretne punkty zaczepienia.
Restart bez komunikatu oznacza zwykle jedno z dwóch: nagłe odcięcie zasilania (zasilacz, listwa, gniazdko, zwarcie) albo twardy błąd sprzętowy (np. procesor, płyta główna, RAM), którego Windows nie zdążył „ubrać” w niebieski ekran. Czasem powodem jest też ustawiony w systemie automatyczny restart po błędzie – wtedy BSOD wyświetla się ułamki sekund, po czym komputer od razu się przeładowuje.
Przy BSOD Windows z reguły rejestruje zdarzenie BugCheck w Podglądzie zdarzeń i zapisuje plik minidump. Przy restarcie bez komunikatu najważniejszym wpisem staje się Kernel-Power 41, który tylko informuje, że system nie został poprawnie zamknięty. To zasadnicza różnica: BSOD daje konkretne kody, niespodziewany restart często jedynie sugeruje, że „coś” nagle odcięło system od prądu lub zatrzymało jądro.
Ryzyko utraty danych i uszkodzenia systemu plików
Każdy nagły restart to ryzyko utraty danych. Pliki otwarte w edytorze tekstu, arkuszu kalkulacyjnym, oprogramowaniu księgowym czy projekcie graficznym mogą zostać częściowo zapisane, a częściowo uszkodzone. Mechanizmy autozapisu ratują tylko część pracy, i to pod warunkiem, że aplikacja zdążyła wykonać ostatni zapis.
Przy częstych, niespodziewanych restartach dochodzi jeszcze ryzyko uszkodzenia systemu plików na dysku. System może zatrzymać się w trakcie zapisu metadanych NTFS, aktualizacji wpisów MFT, operacji na dzienniku transakcyjnym. Po którymś takim incydencie Windows zaczyna uruchamiać się z komunikatem o sprawdzaniu dysku, pojawiają się ostrzeżenia w logach Disk, a w skrajnych przypadkach – brak możliwości startu bez naprawy automatycznej lub ręcznego użycia narzędzi typu chkdsk.
Przy dłuższej serii twardych resetów może dojść również do uszkodzenia profilu użytkownika: znikające ustawienia, resetowane tapety, problemy z logowaniem („Profil użytkownika nie może zostać załadowany”). To pośredni efekt tego, że system był odcinany od zasilania podczas zapisu konfiguracji konta.
Incydent jednorazowy a powtarzający się problem
Pojedynczy niespodziewany restart po burzy, zaniku zasilania lub przypadkowym wciśnięciu przycisku RESET bywa incydentem, który nie wymaga głębokiej diagnostyki. Mimo to warto zajrzeć do Podglądu zdarzeń, aby odnotować przynajmniej Kernel-Power 41 i sprawdzić, czy tuż przed nim nie ma innych błędów.
Jeżeli jednak komputer sam się restartuje cyklicznie – raz dziennie, kilka razy w tygodniu, albo w konkretnych sytuacjach (gra, montaż wideo, kopiowanie dużych plików) – to już sygnał, że coś jest nie tak. W logach zaczyna powtarzać się pewien wzorzec: stały odstęp czasu od startu, ten sam zestaw błędów sprzętowych lub sterowników, te same ostrzeżenia temperatury albo błędy dysku.
Różnica jest zasadnicza: incydent jednorazowy to raczej ciekawostka i ostrzeżenie, by doposażyć się w listwę antyprzepięciową lub UPS. Problem powtarzalny oznacza, że każdy kolejny restart może być tym, po którym system już nie wstanie bez naprawy, a dane na dysku zaczną się sypać. W takiej sytuacji regularne zaglądanie do Podglądu zdarzeń i szukanie przyczyny staje się jednym z priorytetów.
Inny próg tolerancji: komputer do gier vs komputer biurowy
Warto porównać dwa typowe scenariusze. Komputer do gier często pracuje na granicy możliwości sprzętowych: podkręcony procesor, wydajna karta graficzna, duże obciążenie zasilacza, intensywne generowanie ciepła. Niespodziewane restarty pod dużym obciążeniem mogą pojawiać się częściej, ale w tym środowisku użytkownik zwykle szybciej zauważa zależność: nowa gra, nowy sterownik, zwiększenie taktowania i nagle maszyna restartuje się przy konkretnym tytule lub w określonej scenie.
W komputerze biurowym, który głównie otwiera przeglądarkę, pakiet biurowy i programy komunikacyjne, margines błędów powinien być dużo mniejszy. Niespodziewany restart podczas pracy z dokumentami czy aplikacją księgową to realne ryzyko utraty danych firmowych. Tutaj nawet pojedynczy incydent jest sygnałem, by co najmniej sprawdzić logi, stan zasilania i ewentualne błędy dysku.
Granica tolerancji zależy więc od zastosowania sprzętu: w maszynie domowej użytkownik może „przełknąć” jednorazowy restart po nowej grze, ale w komputerze biurowym czy produkcyjnym każdy taki przypadek uzasadnia dokładniejszą analizę Podglądu zdarzeń oraz zrobienie kopii zapasowej ważnych danych, zanim problem się powtórzy.
Podstawy: co to jest Podgląd zdarzeń i kiedy faktycznie pomaga
Struktura logów: źródło, identyfikator i poziom zdarzenia
Podgląd zdarzeń (Event Viewer) to narzędzie, w którym Windows zapisuje właściwie wszystko, co istotne: start i zamykanie systemu, instalacje sterowników, błędy usług, ostrzeżenia sprzętowe, informacje o utracie zasilania czy krytycznych wyłączeniach. Każde takie zdarzenie ma kilka ważnych elementów:
Źródło – komponent systemu lub sterownik, który zgłosił wpis (np. Kernel-Power, Disk, WHEA-Logger, BugCheck).
Identyfikator zdarzenia (Event ID) – numer konkretnego typu zdarzenia (np. 41 dla Kernel-Power, 1001 dla BugCheck).
Poziom – klasyfikacja wagi zdarzenia: Informacje, Ostrzeżenie, Błąd, Krytyczne.
Data i godzina – kluczowe przy porównywaniu z momentem restartu oraz innymi wpisami.
Opis – treść komunikatu, często zawierająca dodatkowy kod błędu, nazwę sterownika, ścieżkę pliku czy status sprzętu.
Przy diagnostyce niespodziewanych restartów interesują głównie poziomy Błąd i Krytyczne, bo to one wskazują problemy, które mogły doprowadzić do wyłączenia lub resetu. Informacje i Ostrzeżenia są przydatne jako kontekst – pokazują, co działo się tuż przed awarią, np. instalacja sterownika czy aktualizacji.
Najważniejsze dzienniki przy problemach z restartami
Podgląd zdarzeń jest podzielony na kilka drzew kategorii. Przy automatycznych restartach interesuje przede wszystkim gałąź Dzienniki systemu Windows, a w niej dziennik System. To tam trafiają informacje o zasilaniu, sterownikach jądra, błędach sprzętowych i krytycznych wyłączeniach.
Drugim ważnym dziennikiem jest Aplikacja. Zawiera błędy konkretnych programów, usług i komponentów Windows, takich jak usługa Windows Update, moduły .NET, serwisy antywirusowe. Przy restartach nie jest tak kluczowy jak System, ale potrafi dopełnić obraz: np. pokaże błędy aktualizacji sterownika graficznego chwilę przed krytycznym Kernel-Power 41.
Warto także zerknąć do dzienników związanych ze sprzętem, np. Microsoft-Windows-WHEA-Logger (jeśli występuje w zakładce „Dzienniki aplikacji i usług”). Wpisy WHEA wskazują na błędy sprzętowe procesora, pamięci, magistrali PCIe – to szczególnie istotne przy restartach pod obciążeniem, gdzie podejrzewa się niestabilność sprzętu.
Kiedy Podgląd zdarzeń jest kluczowy, a kiedy niewystarczający
Podgląd zdarzeń sprawdza się najlepiej w kilku scenariuszach:
Błędy zasilania i wyłączeń – krytyczne wpisy Kernel-Power 41, zdarzenia związane z ACPI (zarządzanie energią), uśpieniem i wybudzaniem.
Problemy dyskowe – źródło Disk, zdarzenia sygnalizujące opóźniony zapis, uszkodzone sektory, brak odpowiedzi dysku.
BugCheck – powiązane z BSOD, zawierają kod błędu i informację o pliku zrzutu pamięci.
Są jednak sytuacje, w których logi systemowe nie wystarczą. Typowy przykład to nagłe odcięcie zasilania z zewnątrz: brak prądu w gniazdku, uszkodzona listwa, przewód zasilający, wypięty kabel. Windows po prostu traci zasilanie, więc nie ma szansy zapisać „bo w tym momencie zabrakło prądu”. Rejestruje dopiero fakt, że podczas poprzedniego uruchomienia system nie został poprawnie zamknięty – czyli znowu Kernel-Power 41 bez dodatkowych szczegółów.
Podobnie jest przy niektórych twardych awariach sprzętu: płyta główna lub zasilacz potrafią się wyłączyć bez zapisania czegokolwiek. W logach widać tylko „lukę w czasie” i krytyczny wpis po ponownym starcie. W takich przypadkach Podgląd zdarzeń jest punktem wyjścia, ale nie da pełnego obrazu bez testów sprzętowych (np. zamiany zasilacza, testu pamięci, monitorowania temperatur).
Windows 10, Windows 11 i starsze wersje – działanie jest to samo
Podgląd zdarzeń obecny jest w Windows od wielu generacji. W Windows 10 i Windows 11 jego układ i działanie są bardzo podobne. Różnice sprowadzają się głównie do kosmetyki interfejsu i nazewnictwa niektórych poddzienników, ale kluczowe elementy – dziennik System, poziomy zdarzeń, identyfikatory – pozostają takie same.
W starszych systemach (Windows 7, 8.1) Podgląd zdarzeń wygląda nieco mniej „nowocześnie”, ale logika jest identyczna: szuka się krytycznych zdarzeń w dzienniku System, filtruje po źródłach (Kernel-Power, Disk, BugCheck) i analizuje czas wystąpienia zdarzeń względem restartu. Dzięki temu większość porad dotyczących analizy restartów w Windows 10 sprawdza się także w Windows 11 i starszych systemach z rodziny NT.
Źródło: Pexels | Autor: Markus Spiske
Przygotowanie do diagnostyki: wyłączenie automatycznego restartu i zbieranie objawów
Jak wyłączyć automatyczne ponowne uruchamianie po awarii systemu
Domyślnie Windows ma włączoną opcję automatycznego restartu po błędzie krytycznym. Efekt jest taki, że przy BSOD system bardzo szybko się resetuje i użytkownik nawet nie zdąży przeczytać kodu błędu. Pierwszym krokiem ułatwiającym diagnozę jest wyłączenie tej opcji.
Aby to zrobić w Windows 10/11:
Otwórz tradycyjny Panel sterowania (np. Win+R → wpisz control → Enter).
Przejdź do System (lub „System i zabezpieczenia” → „System”).
Kliknij Zaawansowane ustawienia systemu po lewej stronie.
W sekcji Uruchamianie i odzyskiwanie kliknij przycisk Ustawienia.
W części „Błąd systemu” odznacz pole „Automatycznie uruchom ponownie”.
Zatwierdź przyciskiem OK.
Od tej pory, jeśli komputer napotka błąd krytyczny prowadzący do BSOD, system zatrzyma się na ekranie błędu do czasu, aż ręcznie go zresetujesz lub wyłączysz. Kod błędu IRQL_NOT_LESS_OR_EQUAL, PAGE_FAULT_IN_NONPAGED_AREA, VIDEO_TDR_FAILURE i podobne stają się widoczne i można je zanotować lub sfotografować, co istotnie pomaga w późniejszej analizie logów i plików minidump.
Dlaczego zatrzymanie systemu na BSOD ułatwia identyfikację błędu
BSOD, choć nieprzyjemny, jest w gruncie rzeczy mechanizmem ochronnym. Zatrzymuje system w momencie niebezpiecznego błędu jądra, aby uniknąć dalszego uszkadzania danych. Wyświetlane na ekranie informacje można połączyć z tym, co później widać w Podglądzie zdarzeń: kod błędu z BSOD zwykle odpowiada wpisowi BugCheck w dzienniku System.
Mając widoczny BSOD, można:
spisać kod błędu (np. 0x0000007E) i nazwę potencjalnie winnego sterownika (np. nvlddmkm.sys – sterownik karty graficznej NVIDIA),
sprawdzić, czy system rzeczywiście utworzył zrzut pamięci (minidump),
porównać czas wystąpienia BSOD z wpisami w Podglądzie zdarzeń.
Dodatkowe ustawienia odzyskiwania: minidumpy i zrzuty pamięci
Samo zatrzymanie systemu na BSOD to jedno, ale przy restartach szczególnie przydają się zrzuty pamięci, które potem są odnotowane w Podglądzie zdarzeń jako BugCheck. W tych samych ustawieniach „Uruchamianie i odzyskiwanie” można skonfigurować sposób zapisywania zrzutów.
W sekcji Zapisywanie informacji o debugowaniu dostępnych jest kilka opcji:
Brak – nic się nie zapisuje, jedynym śladem będzie wpis BugCheck oraz BSOD; to najmniej użyteczna konfiguracja przy diagnostyce.
Mały zrzut pamięci (256 KB) – tzw. minidump, zapisywany domyślnie w katalogu C:WindowsMinidump. W zupełności wystarcza w większości przypadków, a nie zajmuje praktycznie miejsca.
Jądro pamięci lub pełny zrzut pamięci – szczegółowe zrzuty, duże pliki, przydatne głównie przy zaawansowanej analizie w narzędziach typu WinDbg.
Przy typowym domowym lub biurowym PC najlepiej sprawdza się opcja mały zrzut pamięci. Daje rozsądny kompromis: z jednej strony logi BugCheck w Podglądzie zdarzeń zawierają odwołanie do konkretnego pliku minidump, a z drugiej nie trzeba zarządzać wielkimi plikami po kilka gigabajtów. Pełne zrzuty mają sens w środowiskach serwerowych lub gdy komputer trafia do serwisu, który rzeczywiście analizuje je w debuggerze.
Zbieranie objawów: na co zwracać uwagę oprócz samego restartu
Podgląd zdarzeń staje się o wiele łatwiejszy do interpretacji, gdy towarzyszą mu dokładne obserwacje. Dwa identyczne wpisy Kernel-Power 41 mogą mieć zupełnie inne przyczyny, jeśli w jednym przypadku restart następuje w spoczynku, a w drugim – zawsze w tej samej grze lub podczas eksportu wideo.
Przed wejściem do logów dobrze jest zanotować kilka faktów:
Obciążenie w momencie restartu – czy komputer był bezczynny, czy może działał stresujący test, gra, rendering, kompresja?
Temperatury i hałas – czy tuż przed restartem wentylatory wchodziły na wysokie obroty, laptop był gorący, obudowa wyraźnie nagrzana?
Ostatnie zmiany w systemie – aktualizacje Windows, sterowników (zwłaszcza grafiki, chipsetu, SATA/NVMe), instalacja nowego oprogramowania, zmiany w BIOS/UEFI.
Okoliczności zasilania – czy restart nastąpił np. przy podłączeniu/odłączeniu zasilacza w laptopie, włączeniu czajnika lub odkurzacza w tej samej listwie, przełączeniu UPS-a?
Częstotliwość i powtarzalność – czy problem wystąpił raz, czy powtarza się cyklicznie; czy jest wywoływalny konkretną czynnością.
Takie notatki pomagają później zdecydować, które wpisy w Podglądzie zdarzeń traktować jako główne, a które jako szum. Przykład: jeśli restarty pojawiają się tylko w jednej grze i zawsze w ciągu 10 minut, podejrzenie pada na sterownik GPU, temperatury lub zasilacz, a nie na przypadkowe ostrzeżenia z usługi drukarki sprzed tygodnia.
Prosty dziennik użytkownika vs automatyczne narzędzia monitorujące
Przy sporadycznych restartach wystarczy zwykły notatnik: data, godzina, co było uruchomione, jak zachowywał się komputer. Przy częstszych problemach wygodniej porównać logi systemu z automatycznie zbieranymi danymi o podzespołach.
Do monitorowania w czasie rzeczywistym wiele osób stosuje:
HWMonitor, HWiNFO, HWInfo64 – podgląd temperatur, napięć, prędkości wentylatorów.
MSI Afterburner (nie tylko dla MSI) – wykres obciążenia i temperatur GPU/CPU w grach.
CrystalDiskInfo – podstawowe dane S.M.A.R.T. dysków, ostrzeżenia o sektorach itp.
Po połączeniu takiego monitoringu z momentem restartu da się stwierdzić, czy np. temperatura CPU tuż przed resetem sięgała granicznych wartości, czy napięcia 12 V mocno „siadały”. Podgląd zdarzeń pokaże efekty (Kernel-Power, WHEA), a zewnętrzne narzędzia – kontekst sprzętowy. To lepsze podejście niż szukanie jednej „magicznej” przyczyny tylko w logach.
Jak szybko dotrzeć do odpowiednich logów w Podglądzie zdarzeń
Najszybszy start: skrót Win+X vs wyszukiwanie w menu Start
Do Podglądu zdarzeń można dojść kilkoma drogami. W praktyce liczą się głównie dwie:
Win+X → Podgląd zdarzeń – szybka metoda na Windows 10/11; menu kontekstowe w lewym dolnym rogu.
Menu Start → wpisz podgląd zdarzeń / eventvwr → Enter – wygodne, jeśli użytkownik często korzysta z wyszukiwarki.
Technicznie oba sposoby robią to samo – otwierają konsolę MMC z modułem Podglądu zdarzeń. W praktyce osoby diagnozujące więcej maszyn zwykle korzystają z Win+X, bo jest szybsze na zdalnych sesjach i maszynach testowych, natomiast użytkownicy okazjonalni chętniej wpisują nazwę narzędzia w Start.
Kluczowe miejsce: Dzienniki systemu Windows → System
Po uruchomieniu Event Viewer po lewej stronie widać drzewo kategorii. Przy restartach pierwsze miejsce, do którego warto się udać, to:
Dzienniki systemu Windows → System.
Widok domyślny pokazuje wszystko: informacje, ostrzeżenia, błędy, wpisy usług, sterowników, zasilania i ACPI. Przy świeżym restarcie dobry efekt daje sortowanie po Dacie i godzinie (malejąco), tak aby na samej górze były najnowsze wpisy. To podstawowy krok: przewinięcie do momentu restartu i sprawdzenie, jakie zdarzenia statusu „Błąd” lub „Krytyczne” pojawiły się tuż przed nim.
W porównaniu z dziennikiem Aplikacja, który zawiera problemy z programami użytkownika, System pokazuje „serce” systemu: sterowniki jądra, magistrale, dyski, kontrolery zasilania. Jeśli restart ma cokolwiek wspólnego z warstwą sprzętową lub niskopoziomową, tu najczęściej pojawi się pierwszy sensowny ślad.
Skróty, które usprawniają pracę z logami
Event Viewer nie jest najbardziej ergonomicznym narzędziem, ale kilka prostych trików oszczędza sporo czasu:
F5 – odświeżenie widoku po kolejnym restarcie. Wystarczy otworzyć dziennik System raz i po każdej awarii tylko wciskać F5.
Ctrl+F – wyszukiwanie po tekście, np. po „Kernel-Power”, „BugCheck”, „WHEA-Logger”. Dobre, gdy logów jest bardzo dużo.
Sortowanie po kolumnach – kliknięcie nagłówka „Poziom”, „Źródło”, „Identyfikator zdarzenia” grupuje wpisy, co ułatwia szybkie wyłapanie np. kilku kolejnych błędów Disk.
Przy częstych restartach można też zostawić Podgląd zdarzeń otwarty na drugim monitorze i obserwować, co się zapisuje w momencie awarii. To rozwiązanie ma przewagę nad analizą „po fakcie”: daje szansę zobaczyć zapisy sprzed restartu, zanim kolejne uruchomienia systemu „zaleją” log.
Równolegle do ręcznego przeklikiwania logów, w Windows istnieje uproszczony widok awarii: Monitor niezawodności (Reliability Monitor). Uruchamia się go, wpisując w Start: reliability lub monit niezawodności, albo przez Panel sterowania → „Zabezpieczenia i konserwacja” → „Konserwacja” → „Wyświetl historię niezawodności”.
W odróżnieniu od „surowego” Podglądu zdarzeń, Monitor niezawodności scala awarie w formie osi czasu i ocen stabilności. Widać tam m.in.:
instalacje i odinstalowania aktualizacji oraz sterowników.
Przewaga jest taka, że jednym spojrzeniem można sprawdzić, czy restarty zaczęły się np. od konkretnej daty, kiedy zainstalował się nowy sterownik grafiki lub duża aktualizacja Windows. Wadą jest mniejsza szczegółowość – i tak ostatecznie trzeba wejść w Podgląd zdarzeń, aby zobaczyć pełny opis Kernel-Power, BugCheck czy Disk. Dla osoby mniej obeznanej to jednak czytelniejszy punkt startu.
Źródło: Pexels | Autor: Rashed Paykary
Kluczowe wpisy przy restartach: „Kernel-Power 41” i spółka
Kernel-Power 41 – sygnał skutku, nie zawsze przyczyny
Kernel-Power z identyfikatorem zdarzenia 41 jest najczęściej cytowanym wpisem przy niespodziewanych restartach. Pojawia się zawsze, gdy system wykryje, że poprzednie uruchomienie nie zakończyło się poprawnym zamknięciem. To oznacza: twardy reset, utrata zasilania, BSOD bez czasu na pełne zamknięcie lub zacięcie się sprzętu.
Kluczowy fragment opisu zdarzenia 41 często brzmi (w wolnym tłumaczeniu): „Komputer został uruchomiony ponownie po uprzednim nieoczekiwanym zamknięciu”. To raczej protokół skutku niż „winny” awarii. Jednak w szczegółach zdarzenia można znaleźć cenne sygnały:
BugcheckCode – jeśli nie jest równy 0, wskazuje, że przed restartem wystąpił BSOD (kod błędu), ale z jakiegoś powodu nie został poprawnie wyświetlony lub nie zdążono go odczytać.
Parametry 1–4 – rozszerzone dane dla debuggera; same liczby niewiele mówią, ale potwierdzają, że był to „restart po BSOD”, a nie zwykłe odcięcie zasilania.
PowerButtonTimestamp – informacja, czy przycisk zasilania był wciśnięty; bywa pomocna, gdy użytkownik podejrzewa przypadkowe dotknięcie przycisku w obudowie.
Dla porównania: jeśli Kernel-Power 41 ma BugcheckCode = 0 i brak innych śladów BSOD, częściej chodzi o klasyczne „padło zasilanie” lub zadziałanie zabezpieczeń płyty głównej/zasilacza. Wtedy trzeba szukać w innych źródłach: WHEA-Logger, Disk, ACPI, ewentualnie w logach UPS-a, jeśli jest zainstalowany.
BugCheck 1001 – gdy system zgłasza BSOD po fakcie
Drugim ważnym wpisem jest zdarzenie BugCheck o identyfikatorze 1001. Pojawia się ono już po ponownym uruchomieniu systemu, gdy Windows zarejestruje, że poprzednia sesja zakończyła się „sprawdzeniem błędu” (czyli BSOD).
Opis zawiera:
kod błędu (np. 0x0000009F, 0x00000116),
4 parametry specyficzne dla danego rodzaju BSOD,
ścieżkę do pliku minidump (np. C:WindowsMinidump50123-12345-01.dmp).
Jeżeli użytkownik nie zdążył odczytać komunikatu z niebieskiego ekranu lub automatyczny restart był jeszcze włączony, wpis BugCheck w połączeniu z Kernel-Power 41 pozwala odtworzyć, co się stało. Pod względem diagnostycznym można porównać dwa podejścia:
Analiza tylko na podstawie BugCheck i jego kodu – wystarcza, gdy błąd jest typowy (np. 0x0000007B po podmianie kontrolera SATA) i objawy są spójne.
Odczyt minidumpa w debuggerze (WinDbg, BlueScreenView) – przy bardziej złożonych przypadkach, gdy kod BugCheck jest mało mówiący albo pojawia się sporadycznie; pozwala wskazać konkretny sterownik czy moduł.
Przykład z praktyki: laptop restartuje się przy zamykaniu pokrywy. W logach widać Kernel-Power 41, potem BugCheck 1001 z kodem 0x0000009F (DRIVER_POWER_STATE_FAILURE), a w minidumpie – sterownik Bluetooth. Zamiast szukać problemu w zasilaczu albo płycie głównej, wystarczy zaktualizować lub wyłączyć konkretny moduł.
WHEA-Logger – błędy sprzętowe CPU, pamięci i magistrali
Microsoft-Windows-WHEA-Logger to źródło związane z Windows Hardware Error Architecture. Wpisy tego typu (zwykle identyfikatory 18, 19, 20) sygnalizują błędy sprzętowe zgłaszane przez procesor, pamięć, kontroler PCIe czy inne elementy obsługiwane przez WHEA.
Charakterystyczne cechy takich wpisów:
poziom często Ostrzeżenie lub Błąd,
opis zawierający „A fatal hardware error has occurred” lub podobną frazę,
Typowe kategorie komunikatów WHEA
Wpisy WHEA można podzielić na trzy główne grupy, z których każda sugeruje nieco inną ścieżkę diagnostyki:
Błędy korygowalne (Corrected Machine Check) – sprzęt zauważył problem, ale skorygował go „w locie”. System działa dalej, ale przy większej liczbie takich wpisów rośnie ryzyko twardych restartów.
Błędy niekorygowalne (Fatal) – problemu nie dało się naprawić na poziomie sprzętu, więc system zwykle kończy się BSOD-em lub nagłym restartem.
Błędy inicjalizacji – sprzęt zgłasza problemy przy starcie (np. przy inicjacji kontrolera PCIe, CPU, pamięci). Częściej prowadzą do zawieszek przy bootowaniu niż do restartów w trakcie pracy, ale potrafią też objawiać się losowym resetem przy dużym obciążeniu.
Różnica praktyczna jest prosta: pojedyncze, rzadkie ostrzeżenia WHEA przy pracy pod dużym obciążeniem można jeszcze łączyć z niestabilnym OC czy marginalnym zasilaniem. Natomiast powtarzalne błędy niekorygowalne w krótkich odstępach czasu to zwykle sygnał do testów RAM/CPU, sprawdzenia temperatur i napięć, a przy braku poprawy – do rozważenia wymiany konkretnego komponentu.
WHEA-Logger a podkręcanie i profile XMP/DOCP
Przy maszynach z włączonym XMP/DOCP lub ręcznym OC, WHEA jest jednym z pierwszych źródeł, do których opłaca się zajrzeć po restarcie. Dwa typowe scenariusze wyglądają tak:
Po podniesieniu taktowania CPU – pojawiają się błędy WHEA pod obciążeniem (np. w grach lub przy renderingu), czasem poparte BSOD-em WHEA_UNCORRECTABLE_ERROR. Cofnięcie OC lub lekkie podniesienie napięcia Vcore często eliminuje problem.
Po włączeniu profilu XMP pamięci – komputer działa stabilnie w spoczynku, ale przy dużej ilości losowych odczytów/zapisów (gry, kompresja, maszyny wirtualne) zaczynają pojawiać się WHEA-Logger 18/19, a po nich twardy restart. Obniżenie taktowania RAM lub poluzowanie timingów potrafi zlikwidować błędy.
Różnica między „czystym” restartem zasilacza a restartem z udziałem WHEA jest wyraźna w logach: przy problemach z OC zwykle widać co najmniej kilka wpisów WHEA w odstępie kilkunastu–kilkudziesięciu sekund przed Kernel-Power 41. Przy zasilaczu, który „odcina” wszystko, takich wpisów często w ogóle nie ma.
Disk, Ntfs, storport – gdy logi wskazują na problemy z dyskiem
Restart połączony z zatrzymaniem systemu plików lub błędami kontrolera magazynu często zostawia ślad w źródłach Disk, Ntfs, storport, iaStorA / iaStorV (Intel RST) czy sterownikach konkretnych kontrolerów NVMe.
Typowe symptomy w logu System w okolicach restartu:
błędy Disk z opisami typu „The device DeviceHarddiskXDRY has a bad block” lub „did not respond within the timeout period”,
wpisy Ntfs sygnalizujące utratę transakcji dziennika, problemy z zapisem metadanych, wymuszone sprawdzanie spójności woluminu przy następnym starcie,
ostrzeżenia/błędy sterowników kontrolera (storport, iaStorA) o resetach portów, błędach łączności lub przekroczonych timeoutach.
Gdy na osi czasu logu pojawia się sekwencja: kilka błędów Disk/Ntfs → nagły Kernel-Power 41 bez BugCheckCode, szala częściej przechyla się w stronę problemów z dyskiem, kablem SATA, kontrolerem lub zasilaniem sekcji dyskowej. W takiej sytuacji porównuje się zwykle dwa podejścia:
Szybkie sprawdzenie SMART i powierzchni – CrystalDiskInfo, narzędzia producenta SSD, prosty chkdsk /scan. Dobre przy jasnych objawach: dysk „klika”, system długo wstaje, kopiowanie się zawiesza.
Dłuższy test sektorów i logów kontrolera – pełny skan powierzchni, narzędzia diagnostyczne producenta, obserwacja, czy podczas testu generują się nowe błędy Disk w Event Viewerze. Przy sporadycznych restartach, bez innych oznak, to często jedyny sposób, by wychwycić początki degradacji dysku.
Częsta różnica praktyczna: dysk talerzowy z bad sectorami zostawia w logu „lawinę” błędów Disk przed restartem, podczas gdy padający SSD potrafi jedynie zgłosić kilka tajemniczych timeoutów, po czym system po prostu znika. W obu przypadkach logi systemowe są szybszym barometrem niż odczucia użytkownika („czasem coś chrupnie”).
ACPI, ThermalEvents i sterowniki zasilania
Jeśli restart przeplata się z gwałtownym załączaniem wentylatorów, spadkami taktowania CPU albo nagłym gaśnięciem pod obciążeniem, często w logach pojawiają się ślady ze źródeł:
ACPI – zdarzenia związane z zarządzaniem energią, przejściami w stany uśpienia, wybudzania, obsługą przycisków zasilania i pokrywy,
ThermalEvents lub pokrewne – ostrzeżenia o przekroczeniu progów temperaturowych,
sterowniki OEM (Lenovo, Dell, ASUS itp.) nadzorujące profile energetyczne i chłodzenie.
Tu porównuje się zwykle dwie kategorie przypadków:
Maszyny przenośne – częściej chodzi o konflikt między sterownikiem OEM a wbudowanymi mechanizmami Windows (np. przy przejściu w stan uśpienia lub przy zamykaniu pokrywy). W logu System pojawiają się wpisy ACPI/Kernel-General tuż przed Kernel-Power 41 i BugCheck 1001 z kodem związanym z zarządzaniem energią.
Komputery stacjonarne – jeśli temperatura faktycznie rośnie ponad normę, łatwiej wykryć to czujnikami, ale w logach i tak pojawiają się informacje o wymuszonym obniżeniu taktowania lub przejściu w stan awaryjny. Gdy do tego dochodzi brak jakichkolwiek wpisów WHEA czy Disk, podejrzenie pada na sekcję chłodzenia lub zasilacz.
Różnica w podejściu diagnostycznym jest wyraźna: przy laptopach zaczyna się od aktualizacji BIOS/UEFI, sterowników chipsetu i pakietu zarządzania energią producenta. Przy desktopach częściej testuje się kombinację: inny zasilacz, dodatkowy nawiew, czyszczenie radiatorów, a dopiero potem grzebanie w ustawieniach ACPI/UEFI.
Inne źródła powiązane z restartami
Poza Kernel-Power, BugCheck, WHEA i Disk/ACPI, w logu System przewijają się też dodatkowe źródła, które potrafią skierować diagnostykę na właściwe tory:
Service Control Manager – liczne błędy startu lub zatrzymywania konkretnych usług przed restartem mogą sugerować problem programowy, np. konflikt sterowników antywirusa, VPN czy oprogramowania do wirtualizacji.
NetBT, e1cexpress, nvlddmkm, amdkmdag – wpisy specyficzne dla kart sieciowych i graficznych. Sekwencja: utrata sterownika grafiki → ponowne uruchomienie sterownika → Kernel-Power, to częsty trop przy restartach wywołanych GPU.
Volmgr, fvevol – błędy woluminu i szyfrowania (BitLocker) przy nagłych zanikach zasilania. Nie zawsze są przyczyną restartu, ale pomagają potwierdzić, kiedy faktycznie doszło do „twardego” odcięcia dysku.
Takie źródła rzadko występują w izolacji – częściej tworzą „chmurę” błędów poprzedzających nagły zanik. W porównaniu z suchem Kernel-Power 41, te dodatkowe wpisy często pozwalają już wyraźnie wskazać kierunek: sieć, grafika, magazyn, bezpieczeństwo.
Filtrowanie i własne widoki: jak odsiać szum od istotnych zdarzeń
Szybki filtr po poziomie i identyfikatorach zdarzeń
Przy dłuższym działaniu systemu dziennik System potrafi zawierać tysiące pozycji dziennie. Zanim przejdzie się do bardziej zaawansowanych widoków, skuteczny bywa prosty filtr „na wierzchu”. Wystarczy:
w drzewie po lewej kliknąć System prawym przyciskiem myszy,
wybrać Filtruj bieżący dziennik…,
w sekcji Poziomy zdarzeń zaznaczyć tylko Krytyczne, Błąd (w razie potrzeby także Ostrzeżenie),
w polu Identyfikatory zdarzeń wpisać np.: 41, 1001, 18, 19, 20, 6008.
W porównaniu z ręcznym przewijaniem, taki filtr daje szybki „szkielet” najbardziej podejrzanych wpisów. Widać od razu, ile razy wystąpił Kernel-Power, ile było BugChecków i czy w pobliżu przewijają się WHEA albo błędy magazynu. Wadą jest operowanie na jednym dzienniku i dość toporne przełączanie filtrów przy zmianie zakresu analizy.
Własny widok niestandardowy tylko pod restarty
Dla osób, które częściej wracają do diagnostyki restartów, praktyczniejsze jest zdefiniowanie widoku niestandardowego. Różnica względem prostego filtru jest taka, że widok:
można zapisać i wywołać jednym kliknięciem,
obejmuje kilka dzienników jednocześnie (np. System + Aplikacja + logi sterowników),
da się go szybko skopiować na inne maszyny (pliki XML widoków).
Przykładowy prosty widok pod restarty:
W lewej kolumnie kliknąć prawym przyciskiem Widoki niestandardowe → Utwórz widok niestandardowy….
W sekcji Okres logowania ustawić np. „Ostatnie 7 dni” (później można to zmienić).
W Poziomy zdarzeń zaznaczyć: Krytyczne, Błąd, Ostrzeżenie.
W polu Źródła zdarzeń wybrać m.in.: Kernel-Power, BugCheck, Microsoft-Windows-WHEA-Logger, Disk, Ntfs, ACPI, volmgr.
Niżej, w sekcji Dzienniki zdarzeń, zaznaczyć przynajmniej: Dzienniki systemu Windows → System (opcjonalnie także Aplikacja).
Zapisać widok np. jako „Restarty i BSODy”.
Od tej pory zamiast przełączać filtry, wystarczy kliknąć nazwę widoku w lewym panelu. Przy analizie kilku komputerów różnica w ergonomii jest odczuwalna – nie traci się czasu na każdorazowe ustawianie identycznych warunków.
Filtrowanie po słowach kluczowych i treści komunikatów
Klasyczny filtr po poziomie i identyfikatorze dobrze działa przy „czystych” awariach. Przy bardziej złożonych przypadkach (np. konflikt dwóch sterowników, losowe restarty po aktualizacji) przydaje się zawężenie widoku po słowach kluczowych lub fragmencie opisu.
Przykładowe kryteria, z których korzystają administratorzy:
szukanie wpisów zawierających „A fatal hardware error has occurred” w źródle WHEA-Logger,
filtrowanie komunikatów z frazą „has been reset” przy badaniu problemów z kontrolerem dysku lub karty sieciowej,
wyszukiwanie „DRIVER_POWER_STATE_FAILURE” lub innych nazw BSOD w opisie zdarzenia BugCheck.
Można porównać dwa podejścia:
Proste Ctrl+F w bieżącym dzienniku – szybsze, gdy zakres czasowy jest znany i szuka się pojedynczego typu zdarzenia.
Zaawansowany filtr XML w widoku niestandardowym – lepszy, gdy problem wraca od tygodni i trzeba przesiać długi fragment historii po kilku frazach na raz.
Przy okazjonalnym użyciu Event Viewera proste wyszukiwanie zwykle wystarcza. Gdy restartów jest kilkadziesiąt i ciągną się od miesięcy, inwestycja w dobrze przygotowany filtr XML zwraca się za każdym kolejnym podejściem do logów.
Widok niestandardowy z filtrem XML – przykład pod restarty
Dla bardziej zaawansowanych użytkowników i serwisantów praktycznym trikiem jest stworzenie widoku, który jednym ruchem wyciąga wszystkie zdarzenia związane z restartami z kilku źródeł. Można to zrobić, edytując filtr XML widoku niestandardowego.
Przykładowy szablon (koniecznie dopasować do własnych potrzeb):
Najczęściej zadawane pytania (FAQ)
Dlaczego komputer sam się restartuje bez niebieskiego ekranu?
Samoczynny restart bez BSOD najczęściej oznacza nagłe odcięcie zasilania (zasilacz, listwa, gniazdko, zwarcie) albo twardy błąd sprzętowy, którego Windows nie zdążył „złapać” w klasyczny niebieski ekran. Czasem winny jest też włączony automatyczny restart po awarii systemu – BSOD pojawia się wtedy na ułamek sekundy i komputer od razu się przeładowuje.
Różnica jest taka, że przy BSOD system zwykle zapisuje konkretny kod błędu (BugCheck) i plik zrzutu pamięci, a przy twardym restarcie w logach widzisz tylko ogólne zdarzenie Kernel-Power 41 („system nie został poprawnie zamknięty”). To mocna wskazówka, że przyczyna leży bliżej zasilania lub sprzętu niż samego Windowsa.
Czy jednorazowy niespodziewany restart komputera to powód do niepokoju?
Pojedynczy, jednorazowy restart po burzy, chwilowym zaniku prądu czy przypadkowym wciśnięciu przycisku RESET najczęściej jest incydentem, a nie początkiem poważnej awarii. W takiej sytuacji wystarczy zwykle sprawdzić w Podglądzie zdarzeń, czy pojawiło się zdarzenie Kernel-Power 41 i czy tuż przed nim nie widać innych błędów zasilania lub dysku.
Jeśli jednak restarty zaczynają się powtarzać – np. raz dziennie albo co kilka godzin – sytuacja jest inna. Stały wzorzec w logach (te same błędy, ten sam czas od startu, te same obciążające operacje, np. gra czy kopiowanie dużych plików) oznacza, że problem może się pogłębiać i grozi utratą danych lub uszkodzeniem systemu plików.
Jak znaleźć przyczynę samoczynnych restartów w Podglądzie zdarzeń?
Najwięcej informacji daje dziennik System w gałęzi „Dzienniki systemu Windows”. To tam pojawiają się krytyczne wpisy Kernel-Power 41, błędy sterowników, problemy z zasilaniem i komunikaty z ACPI. W praktyce krok jest prosty: sprawdzasz czas restartu i szukasz błędów oraz zdarzeń krytycznych tuż przed nim.
Jako uzupełnienie warto przejrzeć dziennik Aplikacja (np. błędy sterownika grafiki, usług antywirusa) oraz, jeśli jest dostępny, log Microsoft-Windows-WHEA-Logger. Ten ostatni rejestruje błędy sprzętowe procesora, pamięci czy magistrali PCIe i bywa kluczowy przy restartach pod obciążeniem, np. w grach lub podczas montażu wideo.
Co oznacza błąd Kernel-Power 41 i czy da się go „naprawić” w Windows?
Kernel-Power 41 to informacja, że system został wyłączony lub zrestartowany w sposób nieprawidłowy – bez typowej sekwencji zamykania Windows. Ten wpis nie jest przyczyną, tylko skutkiem: mówi, że komputer „stracił grunt pod nogami”, ale nie wskazuje konkretnie, czy zawinił zasilacz, płyta główna, przegrzanie czy zwarcie.
„Naprawianie” Kernel-Power polega więc nie na grzebaniu w samym wpisie, ale na dojściu do źródła: analiza innych błędów z tego samego czasu, test zasilacza, sprawdzenie temperatur, diagnostyka RAM lub dysku. Dwa identyczne komunikaty Kernel-Power 41 mogą mieć zupełnie różne przyczyny, zależnie od otoczenia w logach.
Czy częste restarty mogą uszkodzić dysk lub pliki na komputerze?
Każdy nagły restart to ryzyko, że jakieś dane są w trakcie zapisu. Pliki edytowane w Wordzie, arkusze, projekty graficzne czy bazy danych mogą zostać częściowo zapisane i uszkodzone. Funkcje autozapisu zmniejszają straty, ale nie zabezpieczają sytuacji, gdy system zostaje „odcięty” dokładnie w chwili aktualizacji ważnych metadanych na dysku.
Przy dłuższej serii twardych resetów rośnie też szansa uszkodzenia systemu plików NTFS: pojawiają się komunikaty o sprawdzaniu dysku przy starcie, błędy źródła „Disk” w logach, a w skrajnym przypadku Windows może wymagać automatycznej naprawy lub ręcznego chkdsk. Zdarzają się także uszkodzone profile użytkownika – resetowane ustawienia, problemy z logowaniem.
Czym różni się restart w komputerze do gier od restartu w komputerze biurowym?
Komputer do gier pracuje zwykle bliżej granicy swoich możliwości: obciążony procesor i karta graficzna, wysoka temperatura, duży pobór mocy z zasilacza. Restarty pojawiają się często pod konkretnym obciążeniem (określona gra, scena, test benchmarkiem) i mogą wskazywać na problem ze stabilnością sprzętu, podkręcaniem lub sterownikiem grafiki.
W komputerze biurowym, który służy głównie do przeglądarki, arkuszy i programów księgowych, margines „akceptowalnych” błędów jest znacznie mniejszy. Tutaj nawet pojedynczy niespodziewany restart to realne zagrożenie dla danych firmowych i sygnał do sprawdzenia Podglądu zdarzeń, zasilania i stanu dysku, zamiast czekania „czy się powtórzy”.
Kiedy Podgląd zdarzeń nie wystarczy do zdiagnozowania restartów?
Podgląd zdarzeń jest bardzo użyteczny przy błędach sterowników, problemach z dyskiem i klasycznych BSOD-ach (BugCheck), ale ma ograniczenia przy nagłych odcięciach zasilania lub całkowitych zawieszkach sprzętu. Jeśli komputer po prostu znika z zasilania bez żadnych poprzedzających błędów, w logach zobaczysz tylko Kernel-Power 41 bez dodatkowych wskazówek.
W takim scenariuszu trzeba wyjść poza same logi: porównanie zachowania pod obciążeniem i w spoczynku, test innej listwy lub gniazdka, reset podkręcania do ustawień fabrycznych, test pamięci RAM czy podmiana zasilacza. Podgląd zdarzeń daje wtedy ogólny sygnał „system padł nagle”, a właściwa diagnoza przenosi się na poziom fizycznego sprzętu.
