Co najczęściej powoduje ten błąd
Typowy rozkład przyczyn dla kernel security check failure — od najczęstszych do rzadszych.
- 32%
Sterownik firmy trzeciej źle obsługuje listę dwukierunkową lub obiekt synchronizacji jądra — wywołuje RemoveEntryList dwa razy na tym samym elemencie, zwalnia strukturę bez wypięcia jej z listy albo modyfikuje listę z dwóch wątków bez blokady. Przy następnym przejściu listy jądro widzi, że entry->Flink->Blink nie wskazuje z powrotem na entry, i wywołuje __fastfail z podkodem 3
- 22%
Niestabilna pamięć RAM lub kontroler pamięci w procesorze — wskaźniki Flink/Blink to 64-bitowe adresy, więc przekłamanie pojedynczego bitu wystarczy, żeby lista przestała być spójna i kontrola ją odrzuciła. Najczęstszym wyzwalaczem jest profil XMP/EXPO, którego dana kombinacja płyty, modułów i kontrolera pamięci nie utrzymuje stabilnie, rzadziej faktycznie wadliwa kość lub źle osadzony moduł
- 13%
Przetaktowanie, undervolting albo degradacja procesora — przy niestabilnym napięciu rdzeń wykonuje instrukcję z błędnym wynikiem, a efekt jest identyczny jak przekłamanie w pamięci, tyle że powstaje w rejestrze
- 12%
Uszkodzone pliki systemowe lub metadane NTFS — sterownik albo moduł jądra wczytany z uszkodzonego sektora ma inną zawartość, niż powinien, a struktury odtwarzane z uszkodzonych metadanych systemu plików są niespójne już w momencie załadowania do pamięci. Typowe po nagłym zaniku zasilania w trakcie zapisu lub po przerwanej aktualizacji systemu
- 11%
Konflikt sterowników filtrujących — antywirusów, klientów VPN, systemów anty-cheat, szyfrowania dysku, narzędzi do backupu. Kilka minifiltrów wpina się w tę samą ścieżkę operacji I/O i operuje na współdzielonych strukturach kontekstu; jeden zwalnia kontekst, którego drugi jeszcze używa, i lista tych kontekstów przestaje być spójna
- 6%
Przekroczenie bufora na stosie (podkody 0 i 2) albo naruszenie Control Flow Guard (podkod 10) — sterownik zapisał do lokalnego bufora więcej danych, niż ten mieści, nadpisując ciasteczko stosu i adres powrotu, albo wykonał wywołanie pośrednie pod adres, który nie jest dozwolonym celem. Tym samym mechanizmem objawiają się nieudane próby wstrzyknięcia kodu w jądro przez rootkity
- 4%
Wadliwy nośnik systemowy, jego firmware albo kontroler NVMe — błędne transfery DMA przepisują do pamięci jądra dane inne niż odczytane z nośnika, a zawieszenia kontrolera powodują, że struktury opisujące żądania I/O są zwalniane i wpinane na listy w błędnej kolejności
W jakich sytuacjach spotykamy ten błąd
Konfiguracje i okoliczności, w których ten kod pojawia się najczęściej. Jeśli rozpoznajesz tu swój przypadek, masz od razu wskazówkę, od którego rozwiązania zacząć.
- Po aktualizacji sterownika karty graficznej komputer zatrzymuje się po kilkunastu minutach gry albo przy uruchamianiu przeglądarki z akceleracją sprzętową. W zrzucie powtarzają się dxgkrnl.sys lub dxgmms2.sys, choć rzeczywistym sprawcą jest sterownik producenta układu.
- Świeżo złożony komputer z włączonym profilem XMP lub EXPO: niebieski ekran wypada losowo raz na kilka dni, przy różnych programach, a kod zatrzymania raz to ten, raz zupełnie inny. Po wyłączeniu profilu pamięci awarie ustają.
- Laptop, który zaczął się zawieszać po jednej z aktualizacji funkcji Windows — sterownik Wi-Fi, Bluetooth albo czytnika kart od producenta laptopa, wydany kilka lat wcześniej, przestał być zgodny z nową wersją jądra.
- Komputer z dwoma programami ochronnymi naraz (antywirus firm trzecich plus pozostawiony po poprzednim), albo z antywirusem i klientem VPN, które wpinają swoje minifiltry w tę samą ścieżkę operacji na plikach.
- Komputer z procesorem Intel Core 13. lub 14. generacji, który działał stabilnie przez rok, a potem zaczął sypać coraz częstszymi awariami — zarówno pod obciążeniem, jak i przy prawie bezczynnym systemie.
- Zatrzymanie przy wybudzaniu ze snu albo hibernacji: sterownik wypina swoje struktury z list systemowych przy przejściu w stan uśpienia, a przy powrocie próbuje wypiąć je po raz drugi.
- Komputer po nagłym zaniku zasilania albo po przerwanej aktualizacji systemu: awarie pojawiają się przy operacjach na plikach, a sfc zgłasza uszkodzone pliki, których nie potrafi naprawić.
- Laptop świeżo po serwisie lub po transporcie — rozbudowa pamięci, wymiana dysku, czyszczenie układu chłodzenia. Niedosunięty moduł SO-DIMM daje sporadyczne przekłamania, które objawiają się tym kodem.
- Komputer z aktywnym systemem anty-cheat (Vanguard, EasyAntiCheat, BattlEye) razem z narzędziami do podświetlenia RGB i nakładkami do pomiaru FPS — kilka sterowników niskiego poziomu operujących na tych samych strukturach.
Jak naprawić — rozwiązania krok po kroku
Zacznij od pierwszego — to najprostsze i najczęściej działa. Jeśli nie pomoże, idź dalej.
Krok pierwszy: odczytaj podkod z parametru 1
- Upewnij się, że zrzuty w ogóle powstają: Win+R, wpisz sysdm.cpl, zakładka Zaawansowane, Uruchamianie i odzyskiwanie, Ustawienia, pole „Zapisywanie informacji o debugowaniu" ustaw na „Mały zrzut pamięci (256 KB)". Pliki .dmp trafiają do C:\Windows\Minidump.
- Najprostsza droga: pobierz BlueScreenView (NirSoft) albo WhoCrashed, otwórz najnowszy plik z C:\Windows\Minidump i odczytaj wartość „Parameter 1" oraz nazwy sterowników wymienione przy awarii.
- Droga dokładna: zainstaluj WinDbg (Microsoft Store lub Windows SDK), otwórz zrzut, ustaw symbole poleceniem .sympath srv*C:\Symbols*https://msdl.microsoft.com/download/symbols, potem .reload, potem !analyze -v.
- W wyniku znajdź linię Arg1. Najczęstsze wartości: 0x3 — uszkodzona lista LIST_ENTRY (klasyczny błąd sterownika); 0x0 i 0x2 — przepełnienie bufora na stosie; 0x5 — błędny parametr przekazany do funkcji, która traktuje to jako sytuację krytyczną; 0xa — naruszenie Control Flow Guard; 0xb — zapis do obszaru chronionego przed zapisem; 0x1d — uszkodzone drzewo RTL_BALANCED_NODE.
- Wypisz moduły i stos: lm kv (lista sterowników z datami i wersjami) oraz knL (stos wywołań). Zanotuj wszystko, co nie pochodzi z katalogu C:\Windows\System32\drivers i nie ma w opisie Microsoft Corporation.
- Zapisz sobie te dwie informacje — podkod i nazwę podejrzanego pliku .sys. W następnym kroku porównasz je między awariami i to porównanie, a nie pojedynczy zrzut, wskaże kierunek naprawy.
Krok drugi: porównaj trzy kolejne zrzuty — to rozstrzyga o wszystkim
- Poczekaj, aż uzbiera się co najmniej trzy zrzuty (albo weź trzy ostatnie, jeśli już są). Otwórz każdy po kolei w BlueScreenView i wypisz z nich dwie kolumny: podkod z parametru 1 oraz nazwę pliku .sys wskazanego jako winny.
- Wariant A — ten sam plik .sys i ten sam podkod w każdym zrzucie. To najmocniejsza możliwa poszlaka przeciwko konkretnemu sterownikowi. Przechodzisz od razu do cofnięcia jego ostatniej zmiany i tylko tam. Nie testuj pamięci, nie ruszaj BIOS-u — te kroki są w tym wariancie stratą czasu.
- Wariant B — za każdym razem inny sterownik, różne podkody, a do tego przeplatają się inne kody niebieskiego ekranu (0x1E, 0x50, 0x3B, 0x124). To sygnatura warstwy sprzętowej: pamięci albo procesora. Przechodzisz do kroku o warstwie sprzętowej, a nie do polowania na sterownik — bo sterownik, który tam widzisz, jest za każdym razem inną przypadkową ofiarą.
- Wariant C — ten sam sterownik, ale różne podkody, albo ten sam podkod przy różnych sterownikach z tej samej rodziny (np. same moduły pakietu zabezpieczeń). To wskazuje na konflikt sterowników filtrujących — przechodzisz do kroku o minifiltrach.
- Uzupełnij obraz osią czasu: uruchom perfmon /rel (Monitor niezawodności) i sprawdź, co zostało zainstalowane lub zaktualizowane w dniu pierwszej awarii. Jeśli data pierwszego BSOD-a pokrywa się z instalacją sterownika lub aktualizacji, wariant A jest przesądzony niezależnie od tego, co pokazują zrzuty.
- Jeśli zrzuty w ogóle nie powstają, mimo poprawnego ustawienia z kroku pierwszego, potraktuj to jako osobną informację: brak zapisu zrzutu przy powtarzalnych awariach wskazuje na problem z nośnikiem systemowym albo z plikiem stronicowania.
Wariant A: cofnij zmianę sterownika lub aktualizacji
- Menedżer urządzeń (devmgmt.msc), prawy przycisk na urządzeniu, Właściwości, zakładka Sterownik, przycisk „Przywróć sterownik". Jeśli przycisk jest szary, poprzednia wersja nie została zachowana i trzeba pobrać ją ręcznie.
- Dla karty graficznej zrób pełną podmianę, nie nadpisanie: pobierz starszą wersję ze strony NVIDIA, AMD lub Intel, uruchom komputer w trybie awaryjnym, usuń obecny sterownik programem DDU (Display Driver Uninstaller), dopiero potem zainstaluj starszą wersję.
- Jeśli awarie zaczęły się po aktualizacji systemu: Ustawienia → Windows Update → Historia aktualizacji → Odinstaluj aktualizacje. Z wiersza polecenia to samo robi wusa /uninstall /kb:NUMER, ale przy nowszych aktualizacjach zbiorczych Windows 10 i 11 wusa często odmawia komunikatem, że aktualizacja jest wymagana. Wtedy zostaje ścieżka graficzna albo DISM /Online /Remove-Package /PackageName:NAZWA (nazwę odczytasz z DISM /Online /Get-Packages).
- Zablokowanie ponownej instalacji tej samej wersji sterownika: pnputil /enum-drivers wypisze pakiety jako oemXX.inf. UWAGA — zanim cokolwiek usuniesz, odczytaj z tej listy pole „Original Name" i upewnij się, że to faktycznie ten sterownik, o który ci chodzi. Numer oemXX jest przydzielany dynamicznie i u każdego jest inny, więc skopiowanie przykładowego numeru z internetu usunie u ciebie coś zupełnie innego. Nigdy nie usuwaj w ten sposób sterownika kontrolera dysku ani chipsetu — komputer po restarcie może nie wstać albo zostać bez obrazu.
- Dopiero po tej weryfikacji: pnputil /delete-driver oemXX.inf /uninstall (parametru /force używaj wyłącznie, gdy wiesz, dlaczego zwykłe usunięcie się nie powiodło).
- Jeśli system nie startuje: trzy razy przerwij uruchamianie przyciskiem zasilania, żeby wejść do WinRE, potem Rozwiązywanie problemów → Opcje zaawansowane → Ustawienia uruchamiania → F4 (tryb awaryjny) albo bezpośrednio „Odinstaluj aktualizacje".
- Po cofnięciu używaj komputera normalnie przez 3-7 dni. Jeden dzień bez awarii nic nie dowodzi, jeśli wcześniej niebieski ekran pojawiał się co dwa dni.
Wariant C: wyeliminuj sterowniki filtrujące
- Wypisz aktywne minifiltry: fltmc filters oraz fltmc instances. Zanotuj wszystko, co nie pochodzi od Microsoftu — moduły ESET, Bitdefender, Kaspersky, Sophos, Acronis, Veeam, klientów VPN.
- Zanim odinstalujesz pakiet zabezpieczeń, sprawdź, czy nie obsługuje szyfrowania dysku (Sophos SafeGuard, ESET Full Disk Encryption, Bitdefender Full Disk Encryption, McAfee Drive Encryption, Symantec Endpoint Encryption). Usunięcie agenta przy zaszyfrowanym woluminie oznacza utratę dostępu do wszystkich danych na dysku. W takim wypadku najpierw odszyfruj wolumin do końca albo — na komputerze firmowym — skontaktuj się z administratorem, który ma klucze.
- Dopiero potem odinstaluj antywirus firm trzecich oficjalnym narzędziem czyszczącym producenta (ESET Uninstaller, Bitdefender Uninstall Tool, kavremover i odpowiedniki). Zwykłe „Odinstaluj" z Aplikacji często zostawia sterownik w systemie. Windows automatycznie wróci do Defendera.
- Usuń tymczasowo klienty VPN z własnym sterownikiem sieciowym (OpenVPN TAP, WireGuard, Cisco AnyConnect) oraz systemy anty-cheat: Riot Vanguard (vgk.sys) ładuje się już przy starcie systemu i wymaga pełnej deinstalacji, samo zamknięcie gry nic nie zmienia.
- Zostaw dokładnie jeden pakiet zabezpieczeń. Dwa programy skanujące pliki w locie to klasyczny wyścig na tych samych strukturach kontekstu operacji I/O.
- Przejrzyj pełną listę sterowników: Autoruns (Sysinternals), zakładka Drivers, albo driverquery /v /fo table. Szukaj pozycji starszych niż 3-4 lata, bez podpisu producenta oraz takich, których pochodzenia nie kojarzysz — narzędzia RGB, nakładki do pomiaru FPS, stare sterowniki po odinstalowanych programach.
- Test kontrolny: msconfig, zakładka Usługi, zaznacz „Ukryj wszystkie usługi Microsoft", Wyłącz wszystko, restart. Jeśli w takim stanie awarie znikają, wracaj po kilka usług naraz.
Wariant B: przenieś diagnostykę na warstwę sprzętową
- Ten wariant oznacza, że nie ma sensu szukać winnego sterownika — trzeba sprawdzić, czy pamięć i procesor liczą poprawnie. Zacznij od wyłączenia w BIOS profilu pamięci (XMP / DOCP / EXPO na Disabled) oraz wszystkich ręcznych mnożników, offsetów napięć, PBO i Curve Optimizera. Jeśli nie masz pewności, co było zmieniane, wczytaj „Load Optimized Defaults".
- Używaj komputera normalnie przez 3-7 dni. Jeśli awarie ustały, przyczyną była niestabilność profilu pamięci lub procesora, a nie sterownik.
- Jeśli nie ustały, przetestuj pamięć programem MemTest86 z pendrive'a — minimum 4 pełne przebiegi, przy 32 GB to kilka godzin. Wbudowany mdsched.exe pomija zbyt wiele, żeby na nim polegać. Pojedynczy zgłoszony błąd dyskwalifikuje bieżącą konfigurację.
- W laptopie wyjmij i osadź ponownie moduły SO-DIMM, przecierając wcześniej styki. Niedosunięty moduł po serwisie lub po transporcie to częsta i banalna przyczyna.
- Pełną procedurę testowania pamięci — rozdzielanie wadliwej kości od uszkodzonego slotu, dobór napięć, interpretacja wyników — opisaliśmy przy błędzie MEMORY_MANAGEMENT. Nie ma sensu jej tu powtarzać: mechanizm jest ten sam, zmienia się tylko kod, pod którym system się zatrzymał.
- Jeśli masz procesor Intel Core 13. lub 14. generacji, a awarie narastają z miesiąca na miesiąc mimo fabrycznych ustawień, sprawdź stronę CLOCK_WATCHDOG_TIMEOUT — opisaliśmy tam degradację Vmin Shift, wymagane wersje mikrokodu i zasady przedłużonej gwarancji Intela.
Napraw pliki systemowe i system plików
- Otwórz Wiersz polecenia albo PowerShell jako administrator.
- Uruchom DISM /Online /Cleanup-Image /RestoreHealth — odbuduje magazyn komponentów, z którego korzysta następny krok. Wymaga połączenia z internetem i potrafi trwać kilkanaście minut.
- Potem sfc /scannow — porówna pliki systemowe z magazynem i podmieni te, które się różnią. Kolejność ma znaczenie: sfc bez wcześniejszego DISM-a może nie mieć czym naprawiać.
- Sprawdź system plików: chkdsk C: /scan /perf działa online, bez restartu. Jeśli zgłosi błędy i masz kopię danych, uruchom chkdsk C: /f i zrestartuj. Parametru /r (skan powierzchni) używaj tylko na dysku talerzowym o potwierdzonym dobrym stanie SMART.
- Sprawdź, czy wolumin nie jest oznaczony jako uszkodzony: fsutil dirty query C:
- Otwórz Podgląd zdarzeń (eventvwr.msc) → Dzienniki systemu Windows → System i przefiltruj po źródłach disk, Ntfs, volmgr, storahci oraz BugCheck (zdarzenie 1001). Błędy dysku tuż przed godziną awarii przenoszą diagnozę na nośnik.
- Jeśli sfc zgłasza pliki, których nie potrafi naprawić, i powtarza to po ponownym DISM-ie, następnym krokiem jest naprawcza reinstalacja systemu.
Driver Verifier — gdy sterownik jest podejrzany, ale zrzuty go nie wskazują
- Zanim zaczniesz: Driver Verifier celowo zwiększa liczbę awarii i może uniemożliwić normalny start systemu. Zrób kopię danych, utwórz punkt przywracania (SystemPropertiesProtection) i sprawdź, że tryb awaryjny działa — to twoja droga wyjścia.
- Uruchom polecenie verifier, wybierz „Utwórz ustawienia niestandardowe", zaznacz: Pulę specjalną, Sprawdzanie puli, Wymuszone sprawdzanie IRQL, Śledzenie puli, Wykrywanie zakleszczeń, Weryfikację DMA. Na następnym ekranie wybierz „Wybierz nazwy sterowników z listy" i zaznacz wyłącznie te z pustym polem dostawcy oraz spoza Microsoft Corporation.
- Równoważnie z wiersza polecenia: verifier /standard /driver sterownik1.sys sterownik2.sys. Sama pula specjalna, którą dokumentacja Microsoftu poleca przy uszkodzeniach list: verifier /flags 0x1 /driver sterownik.sys. Bieżące ustawienia sprawdzisz przez verifier /querysettings.
- Zrestartuj i używaj komputera normalnie. Jeśli winny sterownik jest wśród sprawdzanych, system zatrzyma się z kodem 0xC4 (DRIVER_VERIFIER_DETECTED_VIOLATION) albo 0xC1 (SPECIAL_POOL_DETECTED_MEMORY_CORRUPTION) i wskaże plik wprost, zamiast pokazywać ofiarę.
- Po 24-48 godzinach bez awarii wyłącz weryfikację: verifier /reset i restart. Nie zostawiaj Verifiera włączonego na stałe — wyraźnie spowalnia system i zwiększa zużycie pamięci.
- Jeśli system nie startuje z włączonym Verifierem: tryb awaryjny albo Wiersz polecenia z WinRE, tam verifier /reset, potem restart.
- Uczciwie o szansach: Verifier wskaże sprawcę tylko wtedy, gdy przyczyną naprawdę jest sterownik i gdy trafisz z jego doborem do weryfikacji. Przy przyczynie sprzętowej nie da żadnej dodatkowej informacji, a przy podejrzeniu padającego dysku dołoży tylko twardych zatrzymań.
Naprawcza reinstalacja Windows z zachowaniem plików i programów
- Najpierw sprawdź nośnik systemowy: CrystalDiskInfo i atrybuty SMART. Dla NVMe patrz na Percentage Used, Available Spare i Media and Data Integrity Errors; dla SATA na Reallocated Sector Count, Current Pending Sector i Uncorrectable Sector Count. Dysk z ostrzeżeniem wymień, zanim postawisz na nim system od nowa.
- Zrób kopię danych, zanim uruchomisz instalator. Operacja „zachowaj pliki i aplikacje" zwykle przebiega bez strat, ale potrafi się przerwać — przy braku miejsca na dysku, przy niestabilnej pamięci (a tę właśnie podejrzewasz) albo przy zaniku zasilania. Odzyskiwanie danych z przerwanej w połowie reinstalacji jest znacznie trudniejsze niż wcześniejsze skopiowanie folderu użytkownika.
- Sprawdź wersję systemu poleceniem winver i pobierz obraz ISO Windows w tej samej wersji. Zamontuj plik ISO podwójnym kliknięciem.
- Uruchom setup.exe z zamontowanego obrazu z poziomu działającego systemu i wybierz „Zachowaj pliki osobiste i aplikacje". To podmienia wszystkie pliki systemowe i sterowniki wbudowane, zostawiając dane, programy i większość ustawień.
- Po zakończeniu instaluj sterowniki wyłącznie ze strony producenta płyty głównej albo laptopa, w kolejności: chipset, zarządzanie energią i magistrale, sieć, grafika, reszta. Nie używaj „aktualizatorów sterowników".
- Uruchom komputer na minimalnym zestawie sterowników przez kilka dni, zanim doinstalujesz antywirus, VPN i narzędzia dodatkowe.
- Jeśli awarie wracają na świeżym systemie z minimalnym zestawem sterowników, przyczyna jest sprzętowa: pamięć, procesor, płyta główna albo zasilanie. Reinstalacja tego nie naprawi i nie ma sensu jej powtarzać.
Kiedy to przestaje być kwestią oprogramowania
Uszkodzone pliki systemowe da się naprawić narzędziami Windows. Jeśli jednak SFC i DISM kończą się błędem albo błąd wraca po czystej instalacji, uszkodzenia systemu są skutkiem, a nie przyczyną — najczęściej stoi za nimi umierający dysk lub wadliwa pamięć, które psują dane w trakcie zapisu.
Czym ten błąd różni się od podobnych
Najbliższy w bazie jest BAD_POOL_HEADER (0x19) i to z nim ten kod bywa mylony, ale sprawdzana jest inna warstwa: 0x19 pilnuje metadanych alokatora puli (nagłówka bloku pamięci — rozmiaru, typu, znacznika), natomiast 0x139 pilnuje struktur logicznych wewnątrz samych danych: spójności list dwukierunkowych LIST_ENTRY, ciasteczek stosu, celów wywołań pośrednich, zakresów tablic, drzew RTL_BALANCED_NODE. Druga, ważniejsza różnica dotyczy natury zatrzymania i odróżnia ten kod od całej reszty bazy. IRQL_NOT_LESS_OR_EQUAL, PAGE_FAULT_IN_NONPAGED_AREA, KMODE_EXCEPTION_NOT_HANDLED, SYSTEM_SERVICE_EXCEPTION czy UNEXPECTED_KERNEL_MODE_TRAP są reakcją na błąd, który już się wydarzył — procesor zgłosił wyjątek i nie było komu go obsłużyć. 0x139 jest zatrzymaniem prewencyjnym: nic jeszcze nie wybuchło, to sam kod wykrył, że struktura jest niespójna, i celowo wywołał __fastfail, a jądro świadomie pomija przy tym obsługę wyjątków, żeby żaden handler nie mógł kontynuować pracy na uszkodzonym stanie. Trzecie rozróżnienie dotyczy DRIVER_VERIFIER_DETECTED_VIOLATION (0xC4): kontrole prowadzące do 0x139 są wkompilowane w zwykłe, produkcyjne jądro i sterowniki, więc działają zawsze i u każdego użytkownika, podczas gdy 0xC4 pojawia się wyłącznie po ręcznym włączeniu Driver Verifiera. W praktyce 0xC4 bywa wynikiem diagnozowania 0x139. Praktyczna konsekwencja unikalna dla tego kodu: diagnostyki nie prowadzi się tu ani od objawu, ani od pojedynczego zrzutu, tylko od porównania kilku kolejnych awarii. Wartość parametru 1 dzieli przyczyny na klasy, a powtarzalność nazwy sterownika rozstrzyga, czy w ogóle szukać sterownika. Dla odmiany przy MEMORY_MANAGEMENT (0x1A) diagnostyka idzie gałęziami wyznaczonymi przez sam podkod, a przy CLOCK_WATCHDOG_TIMEOUT (0x101) — przez indeks konkretnego rdzenia. Trzy różne kody, trzy różne punkty zaczepienia.
Nie czujesz się pewnie z tymi krokami?
Nasz warsztat zrobi pełną diagnostykę — większość napraw 1-3 dni, skomplikowane przypadki 7+ dni.
Jak zapobiec powtórzeniu
- Sterowniki pobieraj wyłącznie ze strony producenta płyty głównej, laptopa albo układu (NVIDIA, AMD, Intel, Realtek). Programy typu „aktualizator sterowników" dobierają wersje po samym identyfikatorze urządzenia, ignorując wariant sprzętowy, i są jedną z częstszych przyczyn tego kodu.
- Przed każdą zmianą sterownika karty graficznej lub chipsetu utwórz punkt przywracania (SystemPropertiesProtection). W Windows 11 ochrona systemu bywa domyślnie wyłączona — sprawdź to raz i zostaw włączone.
- Sterownik karty graficznej instaluj przez czystą instalację (opcja w instalatorze NVIDIA/AMD albo wcześniejsze usunięcie programem DDU), a nie nadpisując poprzednią wersję. Pozostałości starych modułów jądra to typowe źródło niespójnych struktur.
- Zostaw włączone zapisywanie małych zrzutów pamięci (256 KB) i nie czyść katalogu C:\Windows\Minidump. Bez zrzutów diagnostyka tego kodu sprowadza się do wymiany podzespołów na chybił trafił — a przy nim wymiana niewłaściwego podzespołu jest szczególnie łatwa.
- Trzymaj jeden pakiet antywirusowy i ograniczaj liczbę programów instalujących własne sterowniki filtrujące: VPN-y, narzędzia do „przyspieszania", nakładki do pomiaru FPS, oprogramowanie do podświetlenia RGB, stare narzędzia do montażu obrazów płyt.
- Notuj datę i okoliczności każdej awarii. Przy tym kodzie diagnoza opiera się na powtarzalności, a odtworzenie z pamięci, kiedy zaczęły się problemy i co wtedy instalowano, jest po miesiącu praktycznie niemożliwe.
- Aktualizuj BIOS/UEFI — na procesorach Intel Core 13. i 14. generacji nowszy mikrokod ogranicza degradację narastającą z czasem.
- Raz na kwartał sprawdzaj SMART dysku systemowego i utrzymuj aktualną kopię zapasową. Przy niestabilnej pamięci przekłamane dane trafiają również do zapisywanych plików.
Pytania i odpowiedzi
Decyduje powtarzalność, a nie zawartość pojedynczego zrzutu. Otwórz kilka kolejnych plików z C:\Windows\Minidump. Jeśli w każdym powtarza się ten sam plik .sys spoza Microsoftu i ten sam podkod (zwykle 0x3), stawiaj na sterownik i zacznij od cofnięcia jego ostatniej aktualizacji. Jeśli za każdym razem wskazywany jest inny moduł, podkody się różnią, a do tego przeplatają się inne kody BSOD (0x1E, 0x50, 0x3B, 0x124), to typowa sygnatura niestabilnej pamięci lub procesora.
Może, ale to rzadki scenariusz. Podkody 0, 2 i 10 (przepełnienie bufora na stosie, naruszenie Control Flow Guard) to dokładnie te kontrole, które mają blokować wstrzykiwanie kodu w jądro, więc nieudana próba kończy się takim zatrzymaniem. W praktyce znacznie częściej wywołuje je stary, źle napisany sterownik niż złośliwe oprogramowanie. Skan warto zrobić, ale nie jako pierwszy krok, jeśli awarie zbiegły się w czasie z aktualizacją sterownika.
Niekoniecznie. XMP to fabryczny profil przetaktowania — producent modułów gwarantuje go dla swojego zestawu, ale nie dla każdej kombinacji z konkretną płytą i kontrolerem pamięci wbudowanym w procesor. Jeśli MemTest86 na ustawieniach domyślnych przechodzi 4 przebiegi bez błędu, moduły są sprawne, a niestabilny był sam profil.
Trzy razy przerwij uruchamianie przyciskiem zasilania, żeby wejść do środowiska odzyskiwania (WinRE). Stamtąd: Opcje zaawansowane → Ustawienia uruchamiania → F4, czyli tryb awaryjny. Jeśli w trybie awaryjnym system działa, przyczyną jest sterownik ładowany tylko przy normalnym starcie. Jeśli i tam pada, użyj Wiersza polecenia z WinRE: chkdsk C: /f, sfc /scannow /offbootdir=C:\ /offwindir=C:\Windows, verifier /reset (jeśli wcześniej włączałeś Driver Verifier) oraz opcji „Odinstaluj aktualizacje". Minidumpy z niedziałającego systemu można odczytać, podłączając dysk do innego komputera.
Czysta instalacja usunie przyczynę tylko wtedy, gdy leżała po stronie oprogramowania — uszkodzonych plików systemowych albo sterownika, którego nie udało się namierzyć. Nie naprawi wadliwej kości pamięci, degradującego się procesora ani padającego dysku, a te odpowiadają za istotną część przypadków. Przed reinstalacją warto poświęcić kilka godzin na MemTest86 i sprawdzenie SMART, inaczej można postawić system od zera i po tygodniu zobaczyć ten sam ekran.
Sam bugcheck jest kontrolowanym zatrzymaniem i danych nie niszczy. Ryzyko leży w przyczynie: jeśli pamięć przekłamuje bity, przekłamane dane trafiają również do plików zapisywanych na dysk, a nagłe zatrzymanie w trakcie zapisu może uszkodzić metadane NTFS. Przy podejrzeniu wadliwej pamięci ogranicz pracę na ważnych plikach do czasu wyjaśnienia i zrób kopię.
Mechanizm __fastfail wprowadzono w Windows 8. Systemy bez natywnej obsługi tej instrukcji traktują ją zgodnie z dokumentacją Microsoftu jako naruszenie dostępu albo raportują jako UNEXPECTED_KERNEL_MODE_TRAP. Przyczyny są identyczne, zmienia się wyłącznie sposób raportowania i informacja diagnostyczna: nie ma wtedy podkodu, który wskazywałby, którą kontrolę naruszono.
Jeśli awarie zaczęły się po konkretnej aktualizacji sterownika, cofnięcie jej zwykle rozwiązuje sprawę tego samego dnia. Jeśli przyczyna jest sprzętowa, uczciwy czas to kilka dni: każda zmienna (wyłączenie XMP, jeden moduł RAM, inna wersja sterownika) wymaga potem 3-7 dni normalnego użytkowania, żeby stwierdzić, czy pomogła. Awarie występujące raz na tydzień lub rzadziej diagnozuje się najtrudniej i przy nich nikt uczciwie nie obieca wyniku ani terminu.
Powiązane
Powyższe nie pomogło?
Bezpłatna wstępna diagnoza w warsztacie zajmuje ok. godziny. Po niej wiesz dokładnie co jest uszkodzone i ile kosztuje naprawa — bez zobowiązań.