Niebieski ekran z komunikatem system service exception zwykle oznacza problem w jądrze Windows, najczęściej po stronie sterownika, pamięci albo uszkodzonych danych systemowych. To nie jest błąd, który warto leczyć przypadkowymi poradami z internetu, bo wtedy łatwo zamaskować prawdziwą przyczynę zamiast ją znaleźć. Poniżej pokazuję, jak odróżnić jednorazowy incydent od realnej usterki, co sprawdzić w pierwszej kolejności i kiedy sięgnąć po narzędzia diagnostyczne.
Najkrótsza droga do diagnozy zwykle prowadzi od sterowników do zrzutów pamięci
- Najczęstszym źródłem problemu są sterowniki grafiki, dysku, sieci lub chipsetu.
- Jednorazowy BSOD po aktualizacji nie musi oznaczać awarii sprzętu, ale powtarzalny już tak.
- Warto zacząć od trybu awaryjnego, aktualizacji, zwolnienia miejsca na dysku i naprawy plików systemowych.
- Jeśli błąd wraca, minidump z folderu
C:\Windows\Minidumpdaje więcej niż zgadywanie. - Gdy system działa niestabilnie pod obciążeniem, trzeba brać pod uwagę też RAM, SSD, temperatury i zasilanie.
Co oznacza kod 0x3B i dlaczego nie zawsze winny jest Windows
W praktyce ten błąd mówi tyle: Windows natrafił na wyjątek podczas wykonywania kodu systemowego i zareagował awaryjnym zatrzymaniem pracy. Nie chodzi więc o zwykłą aplikację, którą można po prostu zamknąć, tylko o sytuację, w której zagrożona jest stabilność całego systemu. Ja patrzę na to jak na sygnał ostrzegawczy, a nie gotową odpowiedź o winowajcy.
Najważniejsza rzecz, którą warto zrozumieć, brzmi: sam ekran błędu nie wskazuje jeszcze przyczyny. Ten sam kod 0x3B może pojawić się po konflikcie sterownika, po uszkodzeniu plików systemowych, po problemie z pamięcią RAM, a nawet po drobnej niestabilności wywołanej aktualizacją albo zmianą sprzętu. Dlatego w praktyce rozdzielam dwa scenariusze: pojedynczy incydent i błąd, który wraca w tych samych warunkach.
Jeśli system po jednym restarcie działa normalnie, nie ma sensu od razu robić rewolucji. Jeśli jednak niebieski ekran pojawia się ponownie, zwykle zaczynam od sterowników, bo to one najczęściej pośredniczą między Windows a sprzętem. Właśnie dlatego przy tym błędzie tak łatwo pomylić skutek z przyczyną.
To prowadzi prosto do pytania: co najczęściej psuje się jako pierwsze i po czym rozpoznać, w którą stronę iść dalej.
Najczęstsze przyczyny, które widzę w praktyce
W podobnych przypadkach najczęściej nie chodzi o jedną „magicznie zepsutą” funkcję Windows, tylko o konkretną zmianę, która weszła w konflikt z resztą systemu. Najwięcej problemów widzę po nowych sterownikach, po dołożeniu sprzętu i po próbie „przyspieszenia” komputera kosztem stabilności.
| Sygnał | Co zwykle stoi za problemem | Pierwszy sensowny krok |
|---|---|---|
| Błąd pojawia się po graniu, wybudzeniu z uśpienia albo pracy z grafiką | Sterownik GPU lub konflikt z aktualizacją | Rollback sterownika albo czysta reinstalacja z pakietu producenta |
| Awaria zaczęła się po podłączeniu nowego sprzętu | Konflikt urządzenia, kabla, docka albo peryferium USB | Odłączenie nowego elementu i test bez niego |
| Błąd wraca po większej aktualizacji Windows | Niekompatybilny sterownik lub uszkodzone pliki systemowe | Sprawdzenie sterowników, a potem DISM i SFC |
| Dysk jest prawie pełny | Brak miejsca na pliki tymczasowe, stronicowanie i naprawę komponentów | Zostawić minimum 10-15% wolnego miejsca |
| Komputer był podkręcany lub po undervoltingu | Niestabilny RAM, CPU albo napięcia | Powrót do ustawień domyślnych BIOS/UEFI |
| Crashes są losowe, bez wyraźnego wzorca | Pamięć RAM, SSD albo głębsza korupcja systemu | Analiza zrzutów i test sprzętu |
Jeśli mam wskazać jeden praktyczny wniosek, to jest nim ten: najczęściej problem zaczyna się po zmianie. Nowy sterownik, nowy program zabezpieczający, świeży update, dołożony dysk, dokręcony profil XMP, a czasem po prostu brak wolnego miejsca. To są tropy, które naprawdę skracają diagnozę. A zanim przejdziemy do głębszych narzędzi, warto wiedzieć, co zrobić od razu po awarii.
Co zrobić od razu po awarii
- Zapisz kontekst zdarzenia. Zanotuj, co robiłeś tuż przed awarią: gra, przeglądarka, sen i wybudzenie, kopiowanie plików, instalacja sterownika, podłączenie urządzenia. Bez tego łatwo testować losowe rzeczy.
- Odłącz wszystko, co nowe. Jeśli przed błędem pojawił się nowy dysk, adapter, mysz, klawiatura, hub USB albo stacja dokująca, sprawdź system bez tego dodatku. To najtańszy test, a często najbardziej trafny.
- Jeśli system startuje, zabezpiecz dane. Nie czekałbym z kopią ważnych plików do momentu, aż komputer przestanie wstawać. Przy powtarzalnym BSOD-ie stabilność potrafi się szybko pogorszyć.
- Uruchom tryb awaryjny, jeśli błąd wraca przy normalnym starcie. W trybie awaryjnym Windows ładuje mniej sterowników i usług, więc łatwiej ocenić, czy winny jest system, czy coś doładowywanego przy uruchamianiu.
- Nie wprowadzaj pięciu zmian naraz. Jeśli od razu zaktualizujesz sterowniki, zrobisz naprawę systemu i wyczyścisz pół konfiguracji, potem nie ustalisz, co rzeczywiście pomogło.
- Sprawdź, czy awaria ma wzorzec. Jeżeli BSOD pojawia się zawsze przy tej samej czynności, np. po wybudzeniu laptopa albo po starcie gry, to już jest konkretna wskazówka, a nie przypadek.
Ten etap ma jeszcze jedną zaletę: pozwala odróżnić pojedynczy, przypadkowy reset od realnie powracającego problemu. A kiedy już widać, że błędu nie da się zignorować, przechodzę do naprawy w logicznej kolejności, od najmniej inwazyjnych kroków.
Jak naprawiać problem w odpowiedniej kolejności
Ja zawsze układam naprawę od najbezpieczniejszych ruchów do tych bardziej radykalnych. Dzięki temu nie kasuję danych, nie rozbijam konfiguracji i nie ukrywam przyczyny pod warstwą kolejnych „napraw”. To też dokładnie ten moment, w którym przydaje się cierpliwość, bo nie każda metoda zadziała od razu.
| Krok | Co robię | Dlaczego to ma sens |
|---|---|---|
| 1 | Instaluję najnowsze aktualizacje Windows i sprawdzam sterowniki | Wiele błędów jest skutkiem niezgodności między systemem a sterownikiem |
| 2 | Aktualizuję albo cofam sterownik, który zmienił się tuż przed problemem | To najczęstsze źródło BSOD-ów po aktualizacji grafiki, sieci lub chipsetu |
| 3 | Uruchamiam naprawę obrazu systemu: DISM.exe /Online /Cleanup-image /Restorehealth, a potem sfc /scannow
|
DISM naprawia obraz Windows, z którego korzysta SFC, a SFC sprawdza chronione pliki systemowe |
| 4 | Sprawdzam, czy na dysku jest co najmniej 10-15% wolnego miejsca | Windows potrzebuje przestrzeni na pliki tymczasowe, stronicowanie i naprawy |
| 5 | Robię czysty rozruch albo przywracam system do punktu sprzed awarii | To pomaga odseparować konflikt między usługą, aplikacją i sterownikiem |
| 6 | Jeśli nic nie pomaga, rozważam reset lub świeżą instalację | To już etap, na którym system jako całość może być bardziej uszkodzony niż pojedynczy plik |
W tej sekwencji ważny jest detal: najpierw DISM, potem SFC. To nie jest kosmetyka, tylko logiczna kolejność, bo jeśli obraz Windows jest uszkodzony, SFC może nie mieć z czego odbudować plików. W praktyce oba polecenia działają najlepiej, gdy system ma najnowsze poprawki i komputer zostanie po nich zrestartowany.
Nie zaczynałbym od resetu ustawień czy formatowania tylko dlatego, że błąd wygląda groźnie. Bardzo często winny jest jeden sterownik albo jeden komponent systemu, który da się wskazać i wymienić bez burzenia całego środowiska. Jeśli jednak problem wraca, trzeba wejść poziom głębiej.
Jak zawęzić winowajcę, gdy błąd wraca
W uporczywych przypadkach szukam już nie „czy coś jest nie tak”, ale co dokładnie wywołuje awarię. Najwięcej daje wtedy zrzut pamięci, bo zapisuje ślad tego, co działo się w chwili zatrzymania systemu. Mały zrzut pamięci potrzebuje tylko 2 MB pliku stronicowania na dysku systemowym, a w folderze C:\Windows\Minidump zapisują się pliki .dmp, które później można przeanalizować.
Minidump mówi więcej niż sam ekran błędu
Jeśli widzę, że w folderze minidump pojawiają się kolejne pliki, traktuję je jak materiał dowodowy. Taki zrzut może pokazać listę załadowanych sterowników, ślad stosu wywołań i kod zatrzymania, czyli wszystko to, czego nie da zwykły komunikat na ekranie. Sam plik nie zawsze od razu wskazuje winnego, ale prawie zawsze zawęża pole poszukiwań.
WinDbg przydaje się, gdy chcesz zejść niżej niż zwykła diagnostyka
W WinDbg otwieram zrzut i uruchamiam analizę poleceniem !analyze -v. To pokazuje parametry błędu i często podpowiada, który moduł był aktywny w chwili awarii. Jeśli w śladzie pojawia się konkretny sterownik, np. graficzny, sieciowy albo storage, mam już lepszy punkt startu niż ogólne „Windows się wysypał”.
Driver Verifier to narzędzie dla cierpliwych
Driver Verifier potrafi wyciągnąć na światło dzienne wadliwy sterownik, ale sam może wywoływać kolejne crashe. Dlatego używam go dopiero wtedy, gdy zwykłe kroki nie wystarczają i gdy wiem, że będę umiał wrócić do systemu przez tryb awaryjny albo poleceniem verifier /reset. To narzędzie do diagnozy, nie do „naprawiania na ślepo”.
Jeśli analiza dumpów wskazuje jedną klasę sterownika, wracam do źródła i sprawdzam producenta, wersję pakietu oraz moment instalacji. To zwykle prowadzi szybciej do rozwiązania niż kolejne, ogólne próby. Ale czasem problem wcale nie siedzi w Windowsie.
Kiedy to wygląda na sprzęt, a kiedy na sam system
Najprostszy podział, którego używam, jest taki: jeśli błąd pojawia się po konkretnej zmianie software’owej, najpierw podejrzewam system lub sterownik. Jeśli wraca pod obciążeniem, po podkręcaniu albo bez jasnego wzorca, zaczynam patrzeć szerzej na sprzęt. W praktyce ten rozdział oszczędza mnóstwo czasu.
Pamięć RAM i ustawienia podkręcania
Niestabilny RAM potrafi udawać problem z Windows wyjątkowo przekonująco. Jeśli komputer ma aktywne XMP, EXPO, overclocking albo undervolting, pierwszym testem jest powrót do ustawień domyślnych BIOS/UEFI. Jeżeli po tym BSOD znika, problem nie leży w „zepsutym systemie”, tylko w zbyt ambitnych parametrach pracy podzespołów.
Dysk SSD i kontroler magazynu danych
Gdy awarie pojawiają się przy kopiowaniu plików, uruchamianiu systemu albo wybudzaniu z uśpienia, patrzę na dysk i kontroler. Zapełniony SSD, błędy systemu plików, stare firmware albo uszkodzone sektory logiczne potrafią wywołać losowe zachowanie całego Windowsa. To właśnie dlatego nie ignoruję żadnych oznak spowolnienia zapisu czy dziwnych przycinek przed BSOD-em.
Przeczytaj również: SMB - Udostępnianie plików i drukarek: Jak to działa?
Temperatura i zasilanie
Przegrzewanie, niestabilny zasilacz lub wadliwy dock USB-C też potrafią uruchomić lawinę objawów, które wyglądają jak czysto programowy problem. Jeśli błędy pojawiają się przy wysokim obciążeniu, sprawdzam temperatury CPU i GPU, odpinam zbędne akcesoria i patrzę, czy system staje się stabilniejszy. W laptopach to szczególnie ważne, bo jedna stacja dokująca potrafi zmienić cały profil pracy sprzętu.
Po takim rozdzieleniu zwykle widać, czy nadal walczę z Windows, czy już z konkretnym komponentem. I właśnie to daje ostatni etap: ograniczenie szans na powrót problemu po naprawie.
Jak ograniczyć ryzyko powrotu błędu po naprawie
Po usunięciu awarii nie zostawiałbym systemu w tym samym stanie, w którym błąd się pojawił. Najwięcej daje kilka prostych nawyków, które nie wyglądają spektakularnie, ale realnie zmniejszają ryzyko nawrotu.
- Aktualizuj sterowniki z właściwego źródła. Najlepiej z witryny producenta laptopa, płyty głównej albo karty graficznej, a nie z losowych „updaterów”.
- Nie mieszaj kilku zmian naraz. Jeśli instalujesz nowy sterownik, nie dokładaj od razu kolejnego eksperymentu w BIOS-ie.
- Trzymaj zapas miejsca na dysku. 10-15% wolnej przestrzeni to rozsądne minimum dla codziennej pracy Windows.
- Rób punkt przywracania przed większymi zmianami. To prostsze niż późniejsze cofanie szkód po nieudanej aktualizacji.
- Monitoruj temperatury i zachowanie sprzętu po obciążeniu. Jeśli problem wraca tylko podczas gry albo renderowania, to ważniejsza informacja niż sam kod błędu.
- Nie ignoruj pierwszych ostrzeżeń. Dziwne restarty, przycięcia, czarny ekran po wybudzeniu czy szarpanie obrazu często pojawiają się przed kolejnym BSOD-em.
Jeśli po tych krokach błąd nadal wraca, zwykle szybciej i taniej jest przejść do pełnej diagnostyki sprzętu albo świeżej instalacji Windows niż przez kolejne dni zgadywać, który komponent zawodzi. Właśnie w takich sytuacjach najbardziej liczy się chłodna kolejność działań, a nie liczba wykonanych „napraw”.
