Toshiba i błędy BSOD: jak odczytać kody, znaleźć winny sterownik i ustabilizować system

Kiedy niebieski ekran przerywa pracę: szybkie rozpoznanie i pierwsze ruchy

Zatrzymaj automatyczny restart i zapisz komunikat

Po wystąpieniu BSOD (Blue Screen of Death) laptop Toshiba zwykle restartuje się automatycznie, przez co nie zdążysz odczytać kodu. Najpierw wyłącz automatyczny restart: uruchom Windows, otwórz sysdm.cpl (Start → wpisz „sysdm.cpl”), przejdź do Zaawansowane → Uruchamianie i odzyskiwanie → Ustawienia i odznacz „Automatycznie uruchom ponownie”. Przy następnym BSOD ekran zostanie na miejscu, a Ty spiszesz nazwę błędu (np. IRQL_NOT_LESS_OR_EQUAL), ewentualny plik sterownika (np. nvlddmkm.sys) oraz kod STOP (np. 0x0000000A lub 0xA).

Co oznacza nazwa błędu i plik .sys na ekranie

Nazwa błędu określa typ awarii (logika jądra, sterownik, pamięć). Plik .sys bywa bezpośrednim tropem: jeśli widzisz nvlddmkm.sys – to sterownik NVIDIA; atikmpag.sys – AMD; dxgmms2.sys – warstwa grafiki Microsoft; iaStorAC.sys lub storport.sys – magazyn/dysk; rtwlane.sys – Realtek Wi‑Fi. Kod STOP pomaga w dokumentacji Microsoft i w filtrach narzędzi analitycznych. Spisany komplet: nazwa błędu + plik .sys + kod + czas wystąpienia to fundament dalszej diagnozy.

Kiedy przerwać pracę i wykonać kopię danych

Jeśli BSOD pojawia się częściej niż raz dziennie lub pod obciążeniem (gry, rendering, wiele kart w przeglądarce), zrób kopię najważniejszych plików na zewnętrzny dysk lub do chmury. Przy objawach sprzętowych (głośne wentylatory, wyłączanie pod dotknięciem obudowy, klikający dysk) przerwij diagnostykę programową i wykonaj backup w pierwszej kolejności. Uszkodzony nośnik lub RAM potrafi eskalować się z minuty na minutę.

Jak odczytać kody BSOD i uzyskać pełne zrzuty diagnostyczne

Interpretacja ekranu błędu w Windows 10/11

Nowe odsłony Windows wyświetlają nazwę błędu i czasem plik sterownika. Zeskanuj wzrokiem dolną część ekranu: często pojawia się QR-kod prowadzący do strony Microsoft z ogólną definicją błędu. Nie zadowalaj się tym skrótem – właściwe wskazówki znajdziesz w zrzutach pamięci (minidump) i dziennikach zdarzeń. Zapisz dokładny czas według zegara systemowego; porównasz go potem z logami.

Włącz i sprawdź zrzuty pamięci (minidump)

Aby Windows tworzył minidumpy: sysdm.cpl → Zaawansowane → Uruchamianie i odzyskiwanie → Ustawienia → „Zapisz informacje debugowania”: wybierz „Mały zrzut pamięci (256 KB)”. Upewnij się, że ścieżka to %SystemRoot%Minidump. Zwróć uwagę, czy masz włączony plik stronicowania (pagefile) na dysku systemowym – bez niego zrzutów może nie być. Po następnym BSOD w folderze C:WindowsMinidump pojawi się plik .dmp, który otworzysz w narzędziach analitycznych.

Podgląd zdarzeń i Monitor niezawodności

Otwórz Podgląd zdarzeń (eventvwr.msc) i przejdź do Dzienniki systemu Windows → System. Przefiltruj według poziomu „Błąd” i czasu awarii. Wpis o źródle „BugCheck” zawiera kod i parametry, a „WHEA-Logger” wskaże błędy sprzętowe (np. korekowalne/niekorekowalne). Monitor niezawodności (wpisz „Niezawodność” w menu Start) pokazuje oś czasu z awariami aplikacji, sterowników i Windows Update, co bywa kluczem do korelacji: dziś aktualizacja sterownika, jutro BSOD w grach.

Narzędzia do analizy: od szybkiego wglądu po pełny debug

BlueScreenView i WhoCrashed – szybkie tropy

BlueScreenView i WhoCrashed skanują C:WindowsMinidump i w prostych słowach wskazują podejrzane moduły. Dobre na start: widać listę sterowników zaladowanych w chwili awarii, „Crash Address”, czas i plik winny. Słabość: potrafią utożsamiać ntoskrnl.exe ze sprawcą, co zwykle mija się z prawdą – to tylko jądro, w którym manifestuje się błąd. Traktuj te narzędzia jako radar, nie sąd ostateczny.

WinDbg Preview – diagnoza z detalami

Zainstaluj WinDbg Preview z Microsoft Store. Otwórz plik .dmp, ustaw symbole: wpisz polecenie .symfix, potem .reload. Użyj !analyze -v – dostaniesz nazwę błędu, parametry, „Probably caused by” i stos wywołań. Polecenie lmvm nazwa_sterownika pokaże wersję i ścieżkę pliku .sys. To narzędzie pozwala wyłapać realnego winowajcę, np. konflikt dwóch filtrów dyskowych (antywirus + sterownik Intel RST) lub sterownik touchpada blokujący DPC.

Krótka tabela porównawcza

Ustalenie winnego sterownika: od czystego rozruchu do weryfikatora

Czysty rozruch i tryb awaryjny

Zanim uruchomisz ciężkie działa, sprawdź, czy BSOD znika w środowisku minimalnym. Włącz czysty rozruch: msconfig → Usługi → zaznacz „Ukryj wszystkie usługi Microsoft” → „Wyłącz wszystkie”. W zakładce „Uruchamianie” otwórz Menedżera zadań i wyłącz pozycje startowe. Jeśli BSOD przestaje się pojawiać, winny zwykle leży w sterowniku/komponencie producenta (touchpad, Wi‑Fi, grafika, oprogramowanie zabezpieczające).

Tryb awaryjny (Shift + Restart → Rozwiąż problemy → Opcje zaawansowane → Ustawienia uruchamiania) ładuje tylko podstawowe sterowniki Microsoft. Jeżeli w tym trybie system jest stabilny, zawęź podejrzenia do sterowników firm trzecich.

Driver Verifier – używaj świadomie

Weryfikator sterowników potrafi szybko wyłapać wadliwe .sys, ale potrafi też wywołać BSOD przy każdym starcie. Uruchom verifier.exe → „Utwórz ustawienia standardowe” → zaznacz sterowniki firm trzecich (filtr wg kolumny „Dostawca”). Reprodukuj scenariusz, w którym zwykle pojawia się błąd. Jeżeli system wpada w pętlę BSOD, uruchom środowisko odzyskiwania i wyłącz weryfikator: verifier /reset w wierszu polecenia lub Przywracanie systemu.

W zrzucie z WinDbg po weryfikatorze szukaj „VERIFIER_ENABLED” oraz konkretu w „Probably caused by”. Częste typy: DRIVER_VERIFIER_DETECTED_VIOLATION z nazwą wadliwego modułu.

Filtry dyskowe i sieciowe – cisi sprawcy

Antywirusy, oprogramowanie do szyfrowania lub akceleratory dyskowe dokładają własne filtry (UpperFilters/LowerFilters). Konflikty z Intel RST lub sterownikiem NVMe dają 0x7E, 0xF4, czasem 0x9F. W Menedżerze urządzeń sprawdź Kontrolery IDE/ATA/ATAPI oraz Kontrolery magazynu; rozważ przejście na „Standardowy kontroler SATA AHCI firmy Microsoft”, jeśli RST powoduje błędy i nie potrzebujesz trybu RAID. W sieci podobne zasady dotyczą filtrów NDIS (VPN, firewall). Testowo wyłącz/odinstaluj dodatki i obserwuj Monitor niezawodności.

Skąd brać sterowniki dla laptopów Toshiba/Dynabook i w jakiej kolejności

Źródło ma znaczenie

Najpierw strona wsparcia Dynabook/Toshiba dla Twojego modelu. Tam znajdziesz BIOS/UEFI, „Toshiba System Driver” (lub „System Settings/Value Added”), touchpad, zasilanie i specyficzne komponenty (np. HDD Protection). Następnie chipset (Intel/AMD) i grafika. Dopiero potem Windows Update – by dopełnić drobiazgi. Sterowniki ze stron producentów podzespołów (Intel, AMD, Realtek, NVIDIA) instaluj, gdy OEM nie publikuje aktualnych pakietów lub gdy BSOD wskazuje konkretny moduł i wersja OEM ewidentnie sprawia problemy.

Praktyczna kolejność instalacji

Po reinstalacji lub większych aktualizacjach trzymaj ten porządek: chipset → Intel ME/AMT (jeśli dostępny) → grafika → audio → sieć (LAN/Wi‑Fi/Bluetooth) → magazyn (RST/NVMe) → touchpad → „Toshiba System Driver/Settings” i dodatki (funkcyjne klawisze, panel zarządzania energią) → BIOS/UEFI na końcu, osobno i na zasilaczu.

Szybka checklista: sterowniki o podwyższonym ryzyku

• Wi‑Fi/Bluetooth Realtek/Intel – częste 0x9F (DRIVER_POWER_STATE_FAILURE) po uśpieniu.
• Grafika NVIDIA/AMD – VIDEO_TDR_FAILURE (nvlddmkm.sys/atikmpag.sys) przy akceleracji.
• Intel RST (iaStorAC.sys) – zawieszki/BSOD przy intensywnym I/O, zwłaszcza po migracji systemu.
• Touchpad Synaptics/ELAN – DPC_WATCHDOG_VIOLATION po wybudzeniu lub odłączeniu myszy USB.
• Stare pakiety „Toshiba Value Added/Flash Cards” – konflikty z zarządzaniem energią.

Stabilizacja systemu: zmiany konfiguracyjne, które realnie pomagają

Energia i wybudzanie

W planie zasilania ustaw „PCI Express → Zarządzanie stanem łącza” na „Wyłączone” przy problemach z GPU. W kartach sieciowych w Menedżerze urządzeń odznacz „Zezwalaj komputerowi na wyłączanie tego urządzenia w celu oszczędzania energii” i przełącz tryb oszczędzania energii Wi‑Fi na „Maksymalna wydajność”. Jeżeli pojawia się 0x9F po uśpieniu, testowo wyłącz szybkie uruchamianie (control.exe powercfg.cpl → „Wybierz działanie przycisków zasilania”).

Grafika: czysta instalacja

Przy błędach TDR wykonaj czyste odinstalowanie sterownika grafiki narzędziem DDU w trybie awaryjnym, a następnie zainstaluj wersję ze strony Dynabook lub stabilny pakiet producenta GPU. W przeglądarce/Office wyłącz na próbę akcelerację sprzętową; jeśli BSOD znika, wróć do sterownika z inną wersją.

Integralność systemu

Uruchom kolejno: DISM /Online /Cleanup-Image /RestoreHealth oraz sfc /scannow w podniesionym wierszu polecenia. Błędy plików systemowych potrafią maskować się jako problemy sterowników.

Sprzęt pod lupą: pamięć, magazyn, termika

Pamięć RAM

Test krótkoterminowy: „Diagnostyka pamięci systemu Windows”. Test dokładny: MemTest86 z bootowalnego pendrive, minimum 4 pełne przebiegi. Jeden błąd oznacza wymianę/wyjęcie wadliwej kości lub korektę timingu po aktualizacji BIOS.

Dysk/SSD

Sprawdź SMART w CrystalDiskInfo. Atrybuty relokacji, CRC lub wysokie temperatury to czerwone flagi. Zaktualizuj firmware SSD (narzędzia producenta). Na starszych Toshibach z HDD działających pod kątem wstrząsów wyłącz testowo „HDD Protection”, jeśli sterownik zgłasza błędy w Podglądzie zdarzeń.

Temperatury i zasilanie

WHEA_UNCORRECTABLE_ERROR pod obciążeniem często wynika z przegrzewania. Oczyść układ chłodzenia, wymień pastę, sprawdź, czy BIOS nie ogranicza wentylatora trybem „Silent”. Test obciążenia (CPU/GPU) obserwuj w HWiNFO – jeżeli temperatura skacze i występują korekowalne błędy WHEA, zacznij od serwisu termicznego. Przy niestabilnym zasilaczu/gnieździe zasilania awarie potrafią pojawiać się przy dotknięciu wtyku.

Przykłady z praktyki: szybkie ścieżki naprawy

DRIVER_POWER_STATE_FAILURE po uśpieniu

Objawy: BSOD po zamknięciu pokrywy, wpisy 0x9F w „BugCheck”, Warnings w „Netwtw” lub „rtwlane”. Rozwiązanie: aktualizacja Wi‑Fi/Bluetooth z Dynabook, wyłączenie oszczędzania energii karty, aktualizacja BIOS. Jeżeli po aktualizacji nadal problem, instalacja starszej, stabilnej wersji sterownika.

VIDEO_TDR_FAILURE w grach/przeglądarce

Objawy: 0x116/0x117 z nvlddmkm.sys lub atikmpag.sys. Rozwiązanie: DDU → sterownik OEM lub „long-term” producenta, wyłączenie akceleracji w przeglądarce na czas testów, sprawdzenie zasilania i temperatur, korekta planu zasilania (wysoka wydajność).

WHEA_UNCORRECTABLE_ERROR przy renderingu

Objawy: reset bez BSOD lub 0x124, wpisy WHEA-Logger „Cache Hierarchy Error”. Rozwiązanie: czyszczenie układu chłodzenia, aktualizacja BIOS/ME, test RAM/CPU, przy laptopach z dwoma kośćmi – test na pojedynczym module w pierwszym slocie.

Konfiguracja zrzutów i symboli – diagnoza, która ma sens

Typ i miejsce zrzutu

Ustaw zrzuty tak, by dało się je realnie czytać. Otwórz: sysdm.cpl → Zaawansowane → Uruchamianie i odzyskiwanie → „Zapisz informacje debugowania”: wybierz „Mały zrzut pamięci (256 KB)” lub „Zrzut jądra”. Zrzuty trafią odpowiednio do C:WindowsMinidump oraz C:WindowsMEMORY.DMP. Plik stronicowania na dysku systemowym musi być włączony (automatyczny rozmiar lub ≥ rozmiar RAM dla zrzutu jądra).

Jeśli folder Minidump się nie tworzy: sprawdź uprawnienia NTFS, wyłącz czyściciele „optymalizujące” (potrafią usuwać .dmp), odnotuj kod BugCheck w Podglądzie zdarzeń → System → źródło „BugCheck”.

Symbole i skrócony workflow w WinDbg

Zainstaluj WinDbg Preview z Microsoft Store. Ustaw symbole: File → Settings → „Symbol path”: srv*C:Symbols*https://msdl.microsoft.com/download/symbols. Otwórz minidump i wydaj !analyze -v. Potem doprecyzuj moduł: lmDvm nazwa.sys (zobacz wersję, datę, dostawcę). Przy błędach I/O dopytaj stos IRP: !irp z podanego wskaźnika. W błędach grafiki sprawdź kolejkę DPC: !dpcs. Gdy WinDbg wskaże ntoskrnl.exe, to zwykle objaw – przewiń stos do pierwszego sterownika firm trzecich nad jądrem.

Czytanie kodów STOP i parametrów – szybkie tropy

Sam kod BSOD to kierunek, parametry zawężają cel. Przydatne skróty myślowe:

• 0x9F (DRIVER_POWER_STATE_FAILURE) – parametr 3/4 i stos pokażą urządzenie usypiane/zatrzymywane; zwykle Wi‑Fi, BT, NVMe, grafika.
• 0xA/0xD1 (IRQL) – dostęp do złej pamięci na podwyższonym IRQL; najczęściej filtr sieci/dysk lub sterownik HID (touchpad, mysz USB).
• 0x7E/0x3B – wyjątki w trybie jądra; zobacz ostatni sterownik w stosie i koreluj z „co zmieniono” w Monitorze niezawodności.
• 0x116/0x117 (TDR) – ścieżka grafiki; sterownik GPU, zasilanie, temperatury, akceleracja w aplikacjach.
• 0x124 (WHEA) – sygnał sprzętowy; najpierw termika/zasilanie, potem BIOS/ME, na końcu sterowniki.

Jeżeli parametry wskazują adres pamięci z puli, użyj w WinDbg !pool lub !vm, by potwierdzić typ alokacji – często ujawnia klasę błędu (np. NetIO, storport, dxgkrnl).

Kontrola aktualizacji: sterowniki i BIOS bez niespodzianek

Wstrzymanie problematycznych sterowników

Po odnalezieniu stabilnej wersji zablokuj podmianę z Windows Update. W Edycji Pro: gpedit.msc → Szablony administracyjne → Składniki systemu Windows → Windows Update → „Nie dołączaj sterowników z Windows Update” → Włączone. W Home skorzystaj z narzędzia „Show or hide updates” (wushowhide) i ukryj konkretny pakiet. Dodatkowo: Panel sterowania → System → Zaawansowane ustawienia systemu → Sprzęt → „Ustawienia instalacji urządzeń” → „Nie (urządzenie może nie działać zgodnie z oczekiwaniami)”.

Aktualizacja BIOS/UEFI po stronie Dynabook

Aktualizuj tylko, gdy changelog dotyczy stabilności/zasilania lub sprzętu sprawiającego BSOD. Pobierz plik dla dokładnego modelu/part number. Podłącz zasilacz, naładowana bateria, wyłącz uspianie/hibernację, zamknij aplikacje w tle (AV w tryb pasywny). Nie aktualizuj na niestabilnym systemie – najpierw opanuj BSOD, potem BIOS. Po aktualizacji przywróć ustawienia domyślne UEFI i włącz ponownie TPM/Secure Boot, jeśli wymagane.

Recovery po pętli BSOD – ścieżka minimalna

Szybkie wyjście z pętli

Wejdź do WinRE (trzykrotny przerwany start lub Shift+Restart) i:

– Odinstaluj ostatnią aktualizację funkcji/jakości (jeśli BSOD po Windows Update).
– Uruchom Tryb awaryjny i wykonaj verifier /reset oraz przywrócenie sterownika w Menedżerze urządzeń (Właściwości → Sterownik → „Przywróć sterownik”).
– Przywracanie systemu do punktu sprzed instalacji kłopotliwego sterownika.
– Jeśli WinRE nie widzi systemu plików – sprawdź BitLocker i odszyfruj dysk z kluczem odzyskiwania.

Gdy winny sterownik nie daje się odinstalować

W WinRE otwórz Wiersz polecenia i użyj pnputil: pnputil /enum-drivers (znajdź oemXX.inf powiązany z modułem .sys), następnie pnputil /delete-driver oemXX.inf /uninstall /force. Alternatywnie DISM offline: dism /Image:C: /Get-Drivers → /Remove-Driver. Po starcie w normalnym trybie zablokuj ten pakiet w Windows Update.

Różnice modelowe Dynabook/Toshiba – na co uważać

Pakiety narzędziowe i ich wpływ

W seriach Satellite/Portégé/Tecra krytyczne są: „Toshiba System Driver” (warstwa ACPI), „Function Key”/„Hotkey” oraz „HDD/SSD Alert/Protection”. Starsze „Value Added Package” i „Flash Cards” potrafią konfliktować z nowym Windows – przy BSODach z zasilaniem/ACPI zacznij od aktualizacji lub odinstalowania tych dodatków i zainstaluj nowsze „System Settings/Function Key”. W modelach z czujnikiem ruchu (HDD Protection) testowo wyłącz sterownik, jeśli logi magazynu zgłaszają błędy przy wstrząsach.

Grafika hybrydowa i przełączanie

W laptopach z iGPU+dGPU ogranicz liczbę zmiennych: w UEFI ustaw „dGPU only” lub „iGPU only” na czas testów, a w systemie odinstaluj narzędzia przełączania obrazu (jeśli dostarczone przez OEM) i zainstaluj czyste sterowniki w parze (Intel → restart → NVIDIA/AMD). BSODy TDR często ustępują po wyrównaniu wersji obu pakietów zgodnych z rekomendacją Dynabook dla danego BIOS.

Pakiet diagnostyczny przed zgłoszeniem do serwisu

Co spakować, by skrócić proces

Do archiwum dołącz: ostatnie .dmp z C:WindowsMinidump i MEMORY.DMP (jeśli istnieje), raporty msinfo32.nfo oraz dxdiag.txt, eksport Podglądu zdarzeń (System + Aplikacja, ostatnich 3–7 dni) oraz listę sterowników: pnputil /enum-drivers > drivers.txt. Dodaj numer wersji BIOS i listę ostatnich zmian (instalacje, aktualizacje). Taki pakiet zwykle wystarcza, by wsparcie wskazało winny moduł lub zaproponowało właściwy sterownik/BIOS.

Pamięć i dysk: testy, które naprawdę coś mówią

RAM – jak wyłapać subtelne błędy

Niestabilna pamięć potrafi naśladować błędy sterowników. Objawy: losowe kody (0x1A, 0x50, 0xA, 0x3B), różne moduły w stosie, BSODy pod obciążeniem przeglądarki lub przy budzeniu ze stanu uśpienia. Testuj metodycznie:

1) Uruchom MemTest86 z pendrive’a (UEFI), co najmniej 2–4 pełne przebiegi. Jeśli laptop ma dwie kości, wyjmij jedną i testuj pojedynczo w tym samym slocie. Później zamień sloty – błędy mogą być związane z gniazdem.

2) Gdy MemTest przejdzie, sprawdź obciążeniowo w systemie: TestMem5 (profil anta777) lub dłuższy render/kompilację. Błędy RAMu częściej wychodzą przy długim, mieszanym obciążeniu i wysokiej temperaturze.

3) W laptopach nie wymuszaj profili XMP – trzymaj timingi JEDEC producenta. Miksowanie modułów o różnych timingach bywa stabilne tylko pozornie; przy BSODach testuj na pojedynczym, fabrycznym module.

4) W logach WHEA zwróć uwagę na „Memory Error” i korelowalne błędy „Corrected” – seria takich wpisów przed BSODem to sygnał, że RAM jest na granicy stabilności.

NVMe/SATA – kondycja, sterowniki, firmware

Przy kodach 0xF4/0x7A, zacięciach przy dostępie do dysku i wpisach „storahci/stornvme/iaStorAC” przejdź sekwencję:

1) SMART i temperatura: w HWiNFO/CrystalDiskInfo sprawdź Media and Data Integrity Errors (NVMe), liczniki błędów i throttling. Dyski Kioxia/Toshiba w niektórych seriach Dynabook miały aktualizacje firmware pod stabilność – użyj narzędzia producenta (jeśli dostępne) lub strony Dynabook dla konkretnego modelu.

2) Sterownik magazynu: gdy nie używasz RAID/Optane, zostaw sterownik Microsoft (stornvme/storahci). Intel RST instaluj tylko, jeśli jest wymagany przez OEM i faktycznie obsługuje Twój kontroler. Mieszanka stary RST + nowy Windows często kończy się 0x9F/0x7E.

3) System plików: chkdsk /scan (online), a przy podejrzeniu uszkodzeń dism /Online /Cleanup-Image /RestoreHealth i sfc /scannow. Błędy NTFS/disk w Podglądzie tuż przed BSODem zwykle znaczą I/O, nie „wadliwy ntoskrnl”.

4) Zasilanie i termika dysku: w cienkich modelach NVMe traci wydajność przez temperaturę i generuje timeouty. Prosty test: podnieś laptopa dla lepszego przepływu powietrza, wymuś plan „Wysoka wydajność” i sprawdź, czy TDR/I/O się wyciszają.

Driver Verifier w praktyce, gdy winny sterownik się maskuje

Konfiguracja bez blokady systemu

Używaj Driver Verifier selektywnie, tylko dla sterowników firm trzecich. Otwórz jako administrator: verifier → „Utwórz ustawienia standardowe” → „Wybierz nazwy sterowników z listy” → zaznacz „nie-Microsoft”. Na początek włącz: Special Pool, Force IRQL checking, Pool Tracking, I/O Verification. Zostaw wyłączone: Low Resource Simulation, DDI compliance i DMA – dodasz je później, jeśli brak efektu.

Po restarcie odtwórz błąd i przechwyć minidump. W WinDbg użyj !analyze -v i !verifier 3 – często wprost wskaże sterownik, który naruszył zasady. Gdy system wpadnie w pętlę, wejdź do WinRE i wykonaj verifier /reset z Wiersza polecenia lub uruchom Tryb awaryjny i zresetuj ustawienia.

Typowe „winowajczynie” pod lupą Verifiera

Najczęściej sypią się filtry sieciowe (VPN, antywirus, aplikacje do optymalizacji pingu), sterowniki touchpada/klawiatury (HID), oprogramowanie do przechwytywania obrazu, starsze filtry magazynu (stare RST/StorageCraft) i sterowniki do USB 3.x w stacjach dokujących. Jeśli Verifier wskazuje filtr, usuń go narzędziem producenta i sprawdź, czy BSODy ustąpią bez alternatywy – dopiero potem szukaj zamiennika.

Krótki ślad ETW, gdy BSOD poprzedza przycinka sieci lub I/O

netsh trace i pktmon – lekki zapis zdarzeń

Gdy problem wywołujesz powtarzalnie (np. kopiąc duży plik lub łącząc VPN), zrób krótki ślad:

1) Sieć: netsh trace start capture=yes scenario=InternetClient persistent=no maxsize=256 → odtwórz problem (30–120 s) → netsh trace stop. Powstanie archiwum z ETL. Otworzysz je w Windows Performance Analyzer (WPA) lub dołączysz do pakietu dla wsparcia.

2) Pakiety: pktmon start –capture –comp ndis –pkt-size 0 → reprodukcja → pktmon stop → pktmon pcapng i podejrzenie w Wireshark. To bywa kluczowe przy 0x9F z kartą Wi‑Fi, gdzie pakiety zamierają tuż przed zawieszeniem stosu.

3) I/O: w WPR wybierz profil „Disk I/O” (Light), nagraj 60 s podczas zawieszki, zatrzymaj i przeanalizuj w WPA (graf kolejki dysku, czasy odpowiedzi). Jeśli widać długie time‑outy tuż przed BSODem 0x7A/0xF4, wracamy do sekcji o magazynie: sterownik/firmware/termika.

Stabilizacja po naprawie: małe kroki, duży efekt

Minimalna higiena systemu

Po opanowaniu BSODu utrzymaj spójność konfiguracji. Krótka checklista:

• Utwórz punkt przywracania po każdej większej zmianie sterownika/BIOS.
• Zrób kopię działających pakietów sterowników (INF + katalogi) i zablokuj ich podmianę w Windows Update.
• Raz w miesiącu sprawdź temperatury pod obciążeniem i kondycję dysku (SMART).
• Trzymaj włączone zrzuty minidump i nie używaj „czyścicieli” kasujących .dmp.
• Aktualizuj tylko jeden komponent naraz. Testuj 2–3 dni przed kolejnym krokiem.

Jeżeli po serii zmian BSOD wraca, cofnij ostatni sterownik lub wykonaj naprawcze uaktualnienie miejsca (uruchom instalator tej samej wersji Windows i wybierz „Zachowaj aplikacje i pliki”). Taki ruch często przywraca spójność stosu bez czystej instalacji.

Odczyt błędu w 5 minut: minidump + WinDbg

Najkrótsza ścieżka: otwórz minidump w WinDbg (Preview), ustaw symbole i przeczytaj stos. Polecenia w konsoli:

.symfix → .reload → !analyze -v

Gdy „Probably caused by” wskazuje sterownik firm trzecich, sprawdź jego wersję i datę: lmvm nazwa.sys. Przy błędach z zasilaniem doprecyzuj kontekst: !irp dla IRP z parametrów lub !poaction dla stanu zasilania. Dla WHEA: !errrec adres z !analyze -v – pokaże źródło (CPU/PCIe/NVMe).

Krótka mapa kod → pierwszy ruch:

• 0x9F (DRIVER_POWER_STATE_FAILURE): sprawdź parametr 1 (3/4 zwykle wskazują IRP) i sterownik urządzenia z !irp. Wyłącz usypianie selektywne urządzenia i zaktualizuj sterownik.
• 0x116/0x117 (VIDEO_TDR_*): para sterowników GPU (Intel + NVIDIA/AMD), temperatury i zgodność z BIOS. Wyrównaj wersje, sprawdź TDR po czystej instalacji pakietów.
• 0x124 (WHEA_UNCORRECTABLE_ERROR): sekcja błędu wskaże domenę – jeśli PCIe, testuj NVMe/GPU/dok; jeśli Cache/Bus, sprawdź zasilanie/BIOS/termikę.
• 0x3B, 0xA, 0x50, 0x1A: podejrzenie RAM/sterowników trybu jądra. Najpierw test pamięci, potem Verifier na sterownikach nie‑MS.
• 0x7A/0xF4 (I/O): ślad I/O w WPA, sterownik magazynu (Microsoft vs RST), firmware dysku i temperatura.

Jeśli „ntoskrnl.exe” widnieje jako winny bez kontekstu, przejrzyj 2–3 ramki wyżej w stosie i moduły ładowane tuż przed błędem (kolumna „Timestamp” w lm).

ACPI i stany zasilania: kiedy problemy biorą się z usypiania

Modern Standby kontra S3 – co faktycznie masz

Sprawdź dostępne stany: powercfg /a. Jeśli widać tylko „S0 Low Power Idle”, diagnozuj przejścia S0ix (to nie jest klasyczne S3). Tymczasowe obejścia, które pomagają wychwycić winnego:

1) Wyłącz „Szybkie uruchamianie” (Panel sterowania → Opcje zasilania). Przy problemach z hibernacją: powercfg /h off i retest.

2) W planie zasilania ustaw „Zarządzanie stanem łącza PCI Express” na „Wyłączone” – szybki test na konflikty ASPM.

3) Odetnij „zarządzanie energią” dla karty sieciowej/USB: w Menedżerze urządzeń odznacz „Zezwalaj temu urządzeniu na wznawianie komputera” i „Zezwalaj komputerowi na wyłączanie…”.

Ślady przejść zasilania, które da się porównać z BSOD

Utwórz raporty i sprawdź czasy oraz błędy urządzeń:

powercfg /sleepstudy (S0ix) i powercfg /energy (8–10 min, raport HTML). Jeśli SleepStudy wskazuje długie „Resiliency failures” dla Wi‑Fi lub NVMe tuż przed zawieszeniem, kierunek jest jasny: sterownik/firmware danego urządzenia, ew. wyłączenie oszczędzania energii.

UEFI: bezpieczne przełączniki do testu

W wielu modelach Dynabook/Toshiba warto testowo przestawić: „USB Sleep & Charge” → Off, „Wake on LAN/USB” → Off, „Fast Boot” → Off. Gdy laptop wspiera przełącznik S3/S0ix, sprawdź stabilność w S3 (klasyczne uśpienie), ale tylko jako test – nie każdy model zachowa pełną funkcjonalność w S3 po aktualnych Windows.

Dokowanie i peryferia: osobny tor diagnozy

Thunderbolt/USB‑C: kolejność i aktualizacje

BSODy przy podłączaniu/odłączaniu doku często idą z kontrolera TB/USB i sieci w doku. Kolejność, która ratuje scenariusz:

1) Zaktualizuj BIOS/EC, potem firmware kontrolera Thunderbolt (NVM) i sterownik TB (Intel). Dopiero później aktualizuj sterowniki urządzeń z doku (LAN, audio, czytniki kart).

2) Jeśli dok jest „Alt Mode” bez TB, sprawdź sterownik „USB xHCI” i „Realtek USB GbE”/„ASIX” – odinstaluj wraz z oprogramowaniem pomocniczym i wgraj wersje z witryny Dynabook dla Twojego modelu.

3) Reprodukowalne 0x9F przy odpinaniu: test bez doku, potem z doku bez LAN/monitorów (po kolei odpinaj elementy). Winny filtr sieciowy/USB zwykle zdradza się po odłączeniu jednego segmentu.

DisplayLink: gdy obraz idzie przez sterownik

Stacje na DisplayLink potrafią generować TDR i 0x3B przy starych pakietach. Szybki test: odinstaluj DisplayLink Driver narzędziem producenta, uruchom ponownie i użyj tylko wbudowanych wyjść wideo. Jeśli BSODy znikają, zainstaluj najnowszy DisplayLink zgodny z Twoją wersją Windows i sterownikami GPU, albo rozważ dok w trybie DP Alt Mode/TB (bez DisplayLink).

Szybkie notatki admina: małe automaty, duży porządek

Komendy, które przyspieszają diagnozę

Gdy zbierasz materiał do analizy lub chcesz utrzymać porządek w zmianach, te polecenia oszczędzają czas:

• Lista ostatnio instalowanych sterowników z datą: wevtutil qe Setup /q:”*[System[Provider[@Name=’Microsoft-Windows-DriverFrameworks-UserMode-Install’]]]” /f:text /c:50

• Włącz minidumpy i nadpisywanie pliku: wmic recoveros set DebugInfoType=3 oraz wmic recoveros set OverwriteExistingDebugFile=1

• Szybki przegląd sterowników sieci/grafiki/magazynu: pnputil /enum-drivers | findstr /i „net rtln ndis wifi intel nvidia amd stor nvme ahci rst displaylink”

• Urządzenia wznawiające komputer (częsty trop 0x9F): powercfg -devicequery wake_armed

Prosty nawyk: po udanej korekcie (np. wymiana sterownika Wi‑Fi) zablokuj jego autoaktualizację i zrób punkt przywracania. Jeśli problem wróci, szybciej zawęzisz zakres do jednej zmiany zamiast całego stosu sterowników.

Najczęściej zadawane pytania (FAQ)

Jak zatrzymać automatyczny restart i odczytać kod BSOD w Windows 10/11?

Otwórz Start i wpisz: sysdm.cpl → zakładka Zaawansowane → Uruchamianie i odzyskiwanie → Ustawienia → odznacz „Automatycznie uruchom ponownie”. Przy następnym BSOD ekran pozostanie widoczny.