Wszystkie błędy BSOD

Clock Watchdog Timeout

Jądro Windows pilnuje, czy każdy logiczny rdzeń procesora regularnie przyjmuje przerwanie zegarowe. Jeśli jeden z rdzeni nie odbierze go przez określoną liczbę tyknięć, inny rdzeń zatrzymuje system błędem 0x101 i zapisuje w parametrze 4 indeks rdzenia, który zamilkł. To nie jest zwykłe „zawieszenie na sterowniku" — przerwanie zegarowe ma wyższy priorytet niż praktycznie wszystko inne w systemie, więc jego nieobsłużenie oznacza, że rdzeń albo ma zamaskowane przerwania, albo fizycznie przestał wykonywać instrukcje.

Ten sam błąd bywa zapisywany jako: 0x101 · CLOCK_WATCHDOG_TIMEOUT

Ten błąd wskazuje palcem konkretny rdzeń procesora — czwarty parametr błędu to jego indeks. Najczęstsza przyczyna to niestabilne napięcie z ustawień użytkownika (przetaktowanie, XMP/EXPO, undervolt), a nie awaria sprzętu.

Skocz do rozwiązań

Co najczęściej powoduje ten błąd

Typowy rozkład przyczyn dla clock watchdog timeout — od najczęstszych do rzadszych.

  • 32%

    Niestabilne napięcie rdzenia wynikające z ustawień użytkownika — przetaktowanie, profil XMP/EXPO, undervolt przez Curve Optimizer, Multi-Core Enhancement, źle dobrany Load-Line Calibration. Przy skoku na wyższy stan boost regulator nie nadąża podnieść Vcore, napięcie chwilowo spada poniżej Vmin rdzenia, rdzeń gubi stan i przestaje pobierać instrukcje. Charakterystyczne dla zbyt głębokiego undervoltu: system sypie się w bezczynności i przy lekkim obciążeniu (wtedy pojedyncze rdzenie boostują najwyżej), a przechodzi test Prime95 na wszystkich rdzeniach

  • 18%

    Degradacja lub wada fabryczna procesora — Intel potwierdził dla Core 13. i 14. generacji mechanizm Vmin Shift: obwód drzewa zegarowego wewnątrz rdzenia starzeje się pod wpływem zbyt wysokiego napięcia i temperatury, zmienia się wypełnienie sygnału zegarowego, a rdzeń zaczyna wymagać coraz wyższego napięcia do poprawnej pracy — aż przy fabrycznych ustawieniach po prostu się zawiesza. Sygnał rozpoznawczy: kolejne niebieskie ekrany wskazują ciągle ten sam indeks rdzenia

  • 14%

    Stary BIOS lub mikrokod i błędy w zarządzaniu energią rdzeni — przy wychodzeniu z głębokiego stanu uśpienia (C6/C7) rdzeń dostaje polecenie podniesienia zegara szybciej, niż interfejs SVID zdąży podnieść napięcie, albo wybudza się z niepoprawnie odtworzonym stanem kontrolera przerwań i zostaje z zamaskowanymi przerwaniami. Intel wydał w tej sprawie mikrokod 0x12B (wrzesień 2024) i 0x12F (maj 2025), AMD rozwiązywał analogiczne przypadki kolejnymi wersjami AGESA

  • 12%

    Niewydolne zasilanie — zasilacz lub sekcja VRM płyty głównej nie utrzymuje napięcia przy gwałtownym skoku poboru prądu. Wejście w wymagającą scenę w grze potrafi w milisekundach zwielokrotnić pobór; linia 12 V zapada, VRM obniża Vcore i rdzeń schodzi poniżej progu stabilności. Typowe przy zużytych kondensatorach, zasilaczu po kilku latach pracy, zbyt niskiej mocy dla współczesnej karty graficznej oraz przy zasilaniu procesora jednym rozgałęzionym przewodem EPS zamiast dwoma osobnymi

  • 12%

    Sterowniki niskiego poziomu i warstwy wirtualizacji — sterowniki typu WinRing0.sys, RTCore64.sys czy AsIO*.sys (używane przez narzędzia RGB, sterowania wentylatorami i monitoringu) podnoszą IRQL i odpytują rejestry MSR oraz porty I/O w pętli, a część odwołań wywołuje długi SMI: procesor wykonuje wtedy kod firmware'u płyty z zamaskowanymi przerwaniami i nie widzi zegara. W maszynach wirtualnych ten sam efekt daje przeciążony host

  • 8%

    Przegrzewanie i zły montaż chłodzenia — napięcie minimalne potrzebne rdzeniowi do stabilnej pracy rośnie wraz z temperaturą, więc procesor pracujący przy 95-100 °C przez wyschniętą pastę, zapchany radiator lub krzywo dokręcony chłodnik może zawiesić rdzeń przy napięciu, które w 60 °C było w pełni wystarczające

  • 4%

    Uszkodzenie płyty głównej lub gniazda procesora — wygięte piny w gnieździe LGA, mikropęknięcie lutu pod procesorem w laptopie albo padnięta faza VRM zasilająca określoną grupę rdzeni powodują, że jeden konkretny rdzeń dostaje gorsze napięcie lub gorszy sygnał niż reszta

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ąć.

  • Komputer do gier po włączeniu profilu XMP lub EXPO działa normalnie tygodniami, aż podczas wczytywania nowej sceny w grze wyświetla niebieski ekran z tym kodem — skok poboru mocy zbija napięcie poniżej progu stabilności rdzenia.
  • Użytkownik ustawił undervolt przez Curve Optimizer na Ryzenie, przeszedł godzinny test Prime95 bez błędu, a komputer sypie się w nocy, gdy stoi bezczynnie z otwartą przeglądarką — pojedyncze rdzenie boostują wtedy najwyżej przy najniższym napięciu z krzywej.
  • Stacja z Intel Core i9 13900K lub 14900K, kupiona jako w pełni stabilna, po roku zaczyna zawieszać się coraz częściej na fabrycznych ustawieniach, a kolejne zrzuty wskazują ten sam indeks rdzenia — klasyczny obraz degradacji obwodu zegarowego opisanej przez Intela jako Vmin Shift.
  • Komputer po wymianie karty graficznej na mocniejszy model zaczyna wyświetlać ten błąd przy obciążeniu, mimo że sam procesor nie był ruszany — stary zasilacz nie utrzymuje linii 12 V przy nowym poborze.
  • Maszyna wirtualna z Windows na przeciążonym hoście zatrzymuje się z 0x101, bo hipernadzorca odebrał wirtualnemu rdzeniowi czas procesora na dłużej niż limit watchdoga.
  • Komputer biurowy po 4-5 latach bez czyszczenia zaczyna wyświetlać ten błąd latem, przy wyższej temperaturze w pomieszczeniu — zapchany radiator i wyschnięta pasta podnoszą temperaturę rdzeni na tyle, że fabryczne napięcie przestaje wystarczać.
  • Po instalacji kolejnego programu do sterowania podświetleniem i wentylatorami pojawiają się losowe niebieskie ekrany, bo dwa sterowniki jednocześnie odpytują te same rejestry procesora, blokując rdzeń na czas obsługi przerwania firmware'u.
  • Komputer po prawidłowo wykonanej wymianie procesora zawiesza się zawsze na tym samym rdzeniu — przy montażu wygięło się kilka pinów w jednym rogu gniazda LGA.

Jak naprawić — rozwiązania krok po kroku

Zacznij od pierwszego — to najprostsze i najczęściej działa. Jeśli nie pomoże, idź dalej.

Ustal, który rdzeń się zawiesza — to steruje całą dalszą diagnostyką

Łatwy~20 min
Spróbuj jeśli: Zawsze jako pierwszy krok, przed jakąkolwiek wymianą podzespołów. Zajmuje kwadrans i decyduje o tym, czy szukać dalej w ustawieniach, w zasilaniu, czy w samym procesorze.
  1. Sprawdź, czy system w ogóle zapisuje zrzuty: uruchom sysdm.cpl, zakładka Zaawansowane, Uruchamianie i odzyskiwanie, Ustawienia — w polu zapisu debugowania ma być co najmniej „Mały zrzut pamięci (256 KB)". Pliki lądują w C:\Windows\Minidump.
  2. Szybki odczyt bez debuggera: w PowerShell uruchomionym jako administrator wpisz Get-WinEvent -FilterHashtable @{LogName='System'; Id=1001} -MaxEvents 20 | Format-List TimeCreated, Message. W treści zobaczysz wiersz „The bugcheck was: 0x00000101 (0x…, 0x0, 0x…, 0x…)" — ostatni z czterech parametrów to indeks zawieszonego rdzenia.
  3. Dokładniej: zainstaluj debugger poleceniem winget install Microsoft.WinDbg, otwórz najnowszy plik .dmp z C:\Windows\Minidump i wykonaj !analyze -v. Szukaj linii Arg3 (adres bloku PRCB zawieszonego rdzenia) i Arg4 (indeks rdzenia). Uwaga: stos wywołań, który pokaże debugger, należy do rdzenia wykrywającego, nie do winowajcy — nie traktuj wskazanego tam sterownika jako sprawcy.
  4. Zbierz parametry z co najmniej 3-4 kolejnych awarii i porównaj Arg4. Ten sam indeks za każdym razem to mocna przesłanka za uszkodzonym rdzeniem albo za zbyt agresywnym ustawieniem napięcia dla tego rdzenia. Losowe indeksy wskazują na problem globalny: zasilanie, pamięć, mikrokod, temperatura.
  5. Przełóż indeks na fizyczny rdzeń. W procesorach Intel od 12. generacji indeksy od zera do (2 × liczba rdzeni P − 1) to zwykle wątki rdzeni P, a wyższe indeksy to rdzenie E — np. w 14900K indeksy 0-15 odpowiadają rdzeniom P, a 16-31 rdzeniom E. W Ryzenach z dwoma chipletami (7950X, 9950X) indeksy 0-15 to zwykle CCD0, a 16-31 CCD1. To kolejność typowa, wynikająca z enumeracji APIC, ale nie gwarantowana przez system — zanim uznasz konkretny rdzeń za uszkodzony i zaczniesz reklamację, potwierdź przypisanie w HWiNFO64 albo narzędziem Coreinfo od Sysinternals.

Cofnij wszystkie zmiany napięć i zegarów w BIOS

Łatwy~15 min
Spróbuj jeśli: Zawsze, gdy komputer jest podkręcony, ma włączony XMP/EXPO albo ustawiony undervolt. To rozwiązuje wyraźną większość przypadków 0x101 na komputerach stacjonarnych i nic nie kosztuje.
  1. Wejdź do BIOS-u (Del lub F2 przy starcie) i wczytaj ustawienia domyślne: „Load Optimized Defaults" / „Load Setup Defaults" / F9. To kasuje również ręczne mnożniki i napięcia.
  2. Osobno wyłącz profil pamięci: XMP / DOCP / EXPO ustaw na Disabled. Pamięć zejdzie do 4800 lub 5600 MT/s i komputer będzie odrobinę wolniejszy — na czas testu to bez znaczenia. Niestabilny profil pamięci potrafi zawiesić kontroler pamięci wbudowany w procesor, a to widać jako 0x101.
  3. Wyłącz automatyczne podkręcanie płyty: „Multi-Core Enhancement", „Enhanced Turbo", „CPU Core Ratio = Sync All Cores", „Performance Enhancer". Płyty ASUS, MSI i Gigabyte domyślnie łamią limity Intela i podają wyższe napięcie niż specyfikacja.
  4. W płytach pod Intel 13./14. generacji wybierz profil „Intel Default Settings" (wariant Performance lub Baseline zgodny z modelem procesora). W płytach AM5 sprawdź, czy PBO jest na Auto/Disabled i czy Curve Optimizer ma zerowe offsety na wszystkich rdzeniach.
  5. Jeśli używałeś programów podkręcających spod Windows (Intel XTU, Ryzen Master, MSI Afterburner z profilem CPU, ThrottleStop), odinstaluj je — potrafią przywracać własne ustawienia po każdym starcie systemu.
  6. Testuj przez kilka dni normalnego użytkowania. Jeżeli błędy znikną, wracaj do ustawień pojedynczo, po jednym na tydzień, żeby wiedzieć które było winne.

Rozdziel awarie w bezczynności od awarii pod obciążeniem

Łatwy~15 min
Spróbuj jeśli: Gdy awarie zdarzają się w bezczynności, po wybudzeniu lub przy niskim obciążeniu, a komputer przechodzi testy obciążeniowe bez błędu. Traktuj to jako test diagnostyczny, nie jako docelową konfigurację.
  1. Jeśli niebieskie ekrany pojawiają się przy bezczynności, po powrocie z wygaszacza albo przy lekkiej pracy (przeglądarka, odtwarzanie wideo), a nie w grach — winowajcą są niemal na pewno przejścia między stanami uśpienia rdzeni albo zbyt głęboki undervolt przy wysokim boost.
  2. W PowerShell jako administrator wykonaj kolejno: powercfg /setacvalueindex SCHEME_CURRENT SUB_PROCESSOR PROCTHROTTLEMIN 100 oraz powercfg /setacvalueindex SCHEME_CURRENT SUB_PROCESSOR IDLEDISABLE 1 oraz powercfg /setactive SCHEME_CURRENT. Pierwsze polecenie trzyma minimalny stan procesora na 100%, drugie wyłącza stany bezczynności rdzeni — jądro kręci wtedy pustą pętlę zamiast usypiać rdzeń.
  3. Jeżeli alias IDLEDISABLE nie zostanie rozpoznany, użyj pełnego identyfikatora: powercfg /setacvalueindex SCHEME_CURRENT SUB_PROCESSOR 5d76a2ca-e8c0-402f-a133-2158492d58ad 1
  4. Testuj 2-3 dni. Jeśli błąd zniknął, masz potwierdzenie mechanizmu. To nie jest ustawienie docelowe — procesor pobiera wtedy stale pełną moc, grzeje się i głośniej chodzą wentylatory, a laptop traci połowę czasu pracy na baterii.
  5. Trwałe rozwiązanie realizuj w BIOS: w płytach Intel ustaw „C-States = Enabled", ale „Package C State Limit = C2" i wyłącz C1E; w płytach AMD ustaw „Global C-state Control = Disabled" oraz — przy przypadkowych wyłączeniach w bezczynności — „Power Supply Idle Control = Typical Current Idle". Uwaga: wyłączenie Global C-state Control na części płyt AMD daje efekty uboczne, od gubienia urządzeń USB po wyraźnie wyższy pobór energii w spoczynku. Traktuj je jako ustawienie testowe i wróć do Auto, gdy tylko ustalisz przyczynę.
  6. Cofnij zmiany w Windows po zakończeniu testu: powercfg /setacvalueindex SCHEME_CURRENT SUB_PROCESSOR IDLEDISABLE 0 oraz powercfg /setacvalueindex SCHEME_CURRENT SUB_PROCESSOR PROCTHROTTLEMIN 5 oraz powercfg /setactive SCHEME_CURRENT.

Zaktualizuj BIOS — chodzi konkretnie o wersję mikrokodu

Średni~45 min
Spróbuj jeśli: Gdy komputer ma procesor Intel 13./14. generacji, gdy BIOS ma ponad rok, albo gdy reset ustawień do domyślnych nie pomógł. Nowszy mikrokod nie cofnie już powstałej degradacji krzemu, ale powstrzyma jej postęp.
  1. Sprawdź obecną wersję BIOS: uruchom msinfo32 i odczytaj „Wersja/data systemu BIOS" oraz model płyty głównej w polu „Produkt płyty głównej".
  2. Odczytaj wersję mikrokodu procesora. Najprościej programem HWiNFO64 — w sekcji Central Processor pozycja „Microcode Update Revision". Alternatywnie w rejestrze: HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\CentralProcessor\0, wartość „Update Revision".
  3. Dla procesorów Intel Core 13. i 14. generacji celuj w BIOS z mikrokodem 0x12F (maj 2025) lub nowszym; minimum akceptowalne to 0x12B (wrzesień 2024). Starsze wersje pozwalają procesorowi żądać napięć, które trwale niszczą obwód zegarowy w rdzeniu. Mikrokod 0x12F adresuje w szczególności awarie przy długotrwałej pracy z niskim, jednowątkowym obciążeniem — czyli dokładnie ten scenariusz, w którym 0x101 lubi się pojawiać w bezczynności.
  4. Dla platform AMD AM4 i AM5 pobierz najnowszy BIOS z nowszą wersją AGESA — producent podaje ją w opisie pliku na stronie modelu płyty.
  5. Aktualizuj wyłącznie plikiem z witryny producenta płyty (nie procesora), przez wbudowane narzędzie w BIOS (Q-Flash, M-Flash, EZ Flash) i z pendrive'a sformatowanego w FAT32. Nie aktualizuj spod Windows i nie rób tego przy niestabilnym zasilaniu — przerwana aktualizacja unieruchamia płytę.
  6. Po aktualizacji BIOS resetuje się do domyślnych. Zostaw go tak na czas obserwacji i dopiero potem wracaj do XMP/EXPO.

Przetestuj stabilność, mierząc jednocześnie napięcia i temperatury

Średni~2 godz.
Spróbuj jeśli: Po zresetowaniu BIOS-u i po sprawdzeniu chłodzenia, gdy błąd nadal wraca i trzeba rozstrzygnąć, czy problem leży w procesorze, czy w zasilaniu.
  1. Zanim uruchomisz jakikolwiek test obciążeniowy: sprawdź stan chłodzenia. Testy opisane niżej to najgorętsze obciążenie, jakie da się nałożyć na procesor, a ta strona podejrzewa m.in. wyschniętą pastę, zapchany radiator i niesprawną pompę. Uruchamianie Prime95 na komputerze z uszkodzonym chłodzeniem zamienia problem diagnostyczny w uszkodzony sprzęt. Jeśli masz jakiekolwiek podejrzenia co do chłodzenia, najpierw wykonaj kroki z sekcji o zasilaniu i chłodzeniu.
  2. Uruchom HWiNFO64 w trybie Sensors i obserwuj: VID rdzeni, Vcore (VR VOUT), temperatury poszczególnych rdzeni, temperaturę VRM oraz linie 12 V. Zostaw okno otwarte przez cały test i miej je na widoku — nie odchodź od komputera.
  3. Przerwij test natychmiast, gdy temperatura któregokolwiek rdzenia przekroczy 95 °C albo gdy zobaczysz throttling (spadek zegarów przy stałym obciążeniu). To nie jest wynik do „przeczekania" — to informacja, że dalsza część diagnostyki ma iść w stronę chłodzenia, a nie stabilności napięć.
  4. Test pod pełnym obciążeniem: Prime95 w trybie Small FFTs przez 30 minut oraz OCCT test CPU (tryb Extreme, zestaw danych Large). Wyłapują niestabilność przy wysokim prądzie i niskich zegarach.
  5. Test lekkiego obciążenia pojedynczych rdzeni — dla 0x101 ważniejszy niż powyższy: użyj skryptu CoreCycler, który obciąża jeden rdzeń naraz i wskazuje, przy którym rdzeniu pojawił się błąd. To jedyny praktyczny sposób trafienia w awarie związane z Curve Optimizer i z boostem jednordzeniowym. Grzeje przy tym znacznie mniej niż Prime95.
  6. Dla procesorów Intel 13./14. generacji uruchom dodatkowo y-cruncher, test VT3 — jest w tej rodzinie najczulszy na degradację rdzenia.
  7. Interpretacja: temperatury dobijające do 100 °C oznaczają problem chłodzenia. Vcore zapadające poniżej około 1,0 V w momentach skoku obciążenia wskazuje na zbyt niskie LLC albo słabe zasilanie. Błąd zawsze na tym samym numerze rdzenia w CoreCycler przy fabrycznych ustawieniach oznacza uszkodzony rdzeń.
  8. Uwaga na uczciwość wyniku: brak błędu w testach nie dowodzi, że sprzęt jest sprawny. Awarie 0x101 potrafią występować raz na kilka dni w warunkach, których żaden syntetyczny test nie odtwarza.

Wyeliminuj sterowniki niskiego poziomu i warstwy wirtualizacji

Średni~45 min
Spróbuj jeśli: Gdy sprzęt pracuje na fabrycznych ustawieniach i przechodzi testy stabilności, a awarie mimo to występują — zwłaszcza gdy korelują z uruchomieniem konkretnego programu lub gdy system działa w maszynie wirtualnej.
  1. Odinstaluj oprogramowanie RGB, sterowania wentylatorami i monitoringu: iCUE, Armoury Crate, ASUS AI Suite, MSI Center, Aura Sync, OpenRGB, FanControl, SignalRGB. Odinstalowanie samej aplikacji często zostawia sterownik — sprawdź obecność plików WinRing0x64.sys, RTCore64.sys, AsIO2.sys i AsIO3.sys w C:\Windows\System32\drivers i usuń wpisy narzędziem Autoruns (zakładka Drivers).
  2. Zrób czysty rozruch: msconfig, zakładka Usługi, zaznacz „Ukryj wszystkie usługi firmy Microsoft", wyłącz resztę, następnie w Menedżerze zadań wyłącz wszystkie pozycje autostartu. Restart i kilka dni obserwacji.
  3. Jeżeli problem występuje w maszynie wirtualnej: zmniejsz liczbę przypisanych wirtualnych procesorów tak, by suma vCPU wszystkich uruchomionych maszyn nie przekraczała liczby fizycznych rdzeni hosta, i sprawdź obciążenie hosta w momencie awarii. Wyłącz też zagnieżdżoną wirtualizację, jeśli nie jest potrzebna.
  4. Na gospodarzu sprawdź, czy nie działają jednocześnie dwa hipernadzorcy: Hyper-V (wraz z izolacją rdzenia w Zabezpieczeniach Windows), VirtualBox i VMware Workstation potrafią kolidować. Stan sprawdzisz poleceniem systeminfo — wiersz „Wymagania funkcji Hyper-V".
  5. Jeśli mimo to podejrzewasz sterownik, uruchom Driver Verifier w ograniczonym zakresie: verifier /standard /driver nazwa1.sys nazwa2.sys, i przygotuj się na uruchomienie w trybie awaryjnym z poleceniem verifier /reset, gdyby system przestał startować. Nie włączaj weryfikatora dla wszystkich sterowników naraz.

Sprawdź zasilacz, sekcję zasilania i chłodzenie

Średni~1 godz. 30 min
Spróbuj jeśli: Gdy awarie pojawiają się pod obciążeniem, przy skokach mocy (wczytywanie gry, start renderowania), po kilku latach pracy komputera, albo gdy HWiNFO pokazuje zapady na liniach zasilania i wysokie temperatury.
  1. Sprawdź okablowanie procesora: nowoczesne płyty wymagają jednego lub dwóch pełnych złączy EPS 8-pin, każdego osobnym przewodem z zasilacza. Jeden przewód z rozgałęzieniem na dwie wtyczki nie wystarczy dla procesora pobierającego 250 W.
  2. Oceń zasilacz: wiek (po 5-7 latach kondensatory tracą pojemność), moc względem sumy poboru procesora i karty graficznej z zapasem 30% oraz standard. Najpewniejszy test to podmiana na sprawny zasilacz o znanej jakości — pomiar multimetrem nie wykryje krótkich zapadów.
  3. Sprawdź kondensatory na płycie wokół gniazda procesora: wybrzuszona lub rozerwana góra, ślady elektrolitu, przebarwienia — to dyskwalifikuje płytę.
  4. Chłodzenie: zdejmij chłodnik, wyczyść radiator i wentylatory ze sprasowanego kurzu, wymień pastę termoprzewodzącą, sprawdź równomierność docisku (odcisk pasty na pokrywie procesora powinien być równy). W chłodzeniach cieczą sprawdź, czy pompa pracuje — dłoń przyłożona do bloku wyczuwa jej wibrację.
  5. Zapewnij chłodzenie sekcji VRM: przy podkręconym procesorze temperatura VRM powyżej 100 °C powoduje ograniczanie prądu i zapady napięcia. Dołóż nawiew na górną część płyty.
  6. W laptopach dołóż kontrolę stanu baterii (powercfg /batteryreport) i sprawdź, czy oryginalny zasilacz ma odpowiednią moc — zastępczy o niższej mocy powoduje zapady napięcia pod obciążeniem.

Wymiana procesora, reklamacja i kontrola gniazda

Zaawansowany~2 godz.
Spróbuj jeśli: Gdy komputer pracuje na ustawieniach domyślnych, ma aktualny BIOS, sprawne zasilanie i chłodzenie, a błąd 0x101 nadal wraca — szczególnie gdy parametr 4 wskazuje ciągle ten sam indeks rdzenia.
  1. Zanim wyjmiesz procesor, zastanów się, czy to na pewno twój krok. Dla kogoś, kto nigdy tego nie robił, wyjmowanie procesora z gniazda LGA to najprostsza droga do wygięcia pinów — czyli do zamiany problemu diagnostycznego w zniszczoną płytę główną. Prostowanie pinów jest pracą serwisową pod mikroskopem, nie domową. Pamiętaj też, że ponowny montaż wymaga wyczyszczenia pokrywy i nałożenia nowej pasty termoprzewodzącej.
  2. Jeśli decydujesz się sam: obejrzyj gniazdo pod jasnym światłem, przez lupę albo w powiększeniu ze zdjęcia telefonem. Wygięte, złamane lub sklejone piny w jednym obszarze gniazda tłumaczą, dlaczego zawiesza się zawsze ten sam rdzeń.
  3. Sprawdź spód procesora i pokrywę: wypalenia, przebarwienia styków, ślady po zwarciu.
  4. Test rozstrzygający: uruchom komputer z innym, sprawnym procesorem tego samego gniazda. Jeżeli 0x101 znika, procesor jest uszkodzony. Jeżeli występuje nadal, problemem jest płyta albo zasilanie.
  5. Reklamacja przy procesorach Intel Core 13. i 14. generacji: Intel przedłużył gwarancję o dwa lata z powodu wady Vmin Shift. Dla procesorów pudełkowych oznacza to pięć lat od daty zakupu i zgłoszenie idzie bezpośrednio do wsparcia Intela. Jednostki w wersji tray oraz montowane fabrycznie w gotowych komputerach obsługuje producent systemu, a nie Intel — zgłoszenie kierujesz do niego. Program obejmuje imienną listę modeli, więc przed zgłoszeniem sprawdź na niej swój procesor. Przygotuj dowód zakupu, model i numer partii z pokrywy.
  6. W laptopach procesor jest zwykle wlutowany — wymiana oznacza wymianę płyty głównej. Przed decyzją zleć pomiar sekcji zasilania procesora, bo koszt naprawy fazy zasilania bywa wielokrotnie niższy niż koszt płyty.
  7. Uczciwe oczekiwania: degradacja krzemu jest nieodwracalna. Podniesienie napięcia w BIOS może na jakiś czas ukryć objaw, ale przyspiesza dalsze niszczenie rdzenia — to nie jest naprawa, tylko odroczenie.

Kiedy to przestaje być kwestią oprogramowania

Ten błąd wskazuje na usterkę sprzętu, a nie systemu. Jeśli pojawia się już przy starcie, przed załadowaniem Windows, albo wraca po wymianie dysku i czystej instalacji, przyczyny szukamy w sekcji zasilania płyty, procesorze lub karcie graficznej. Diagnostyka na tym poziomie wymaga pomiarów, nie narzędzi systemowych.

Czym ten błąd różni się od podobnych

Najbliższy kod w bazie to DPC_WATCHDOG_VIOLATION (0x133) i różnica jest zasadnicza, choć nazwy brzmią podobnie. Przy 0x133 rdzeń żyje i wykonuje kod — po prostu za długo siedzi na poziomie IRQL DISPATCH_LEVEL lub wyżej, więc winowajca (sterownik) jest widoczny na stosie wywołań i diagnostyka idzie w stronę oprogramowania. Przy 0x101 rdzeń nie przyjął nawet przerwania zegarowego, które ma priorytet ponad DISPATCH_LEVEL — to znaczy, że ma zamaskowane przerwania albo w ogóle przestał wykonywać instrukcje, a stos w zrzucie należy do rdzenia wykrywającego, nie do sprawcy. Dlatego 0x101 przenosi środek ciężkości z pytania „który sterownik" na pytanie „czy rdzeń dostaje właściwe napięcie i zegar": przetaktowanie, undervolt przez Curve Optimizer, stany C, mikrokod i degradacja krzemu. Od SYNTHETIC_WATCHDOG_TIMEOUT różni się tym, że tam licznik odmierza hipernadzorca dla partycji wirtualnej, a tu zwykłe jądro na fizycznym rdzeniu sąsiada. Od WHEA_UNCORRECTABLE_ERROR (0x124) i MACHINE_CHECK_EXCEPTION (0x9C) różni się źródłem informacji: tam procesor sam zgłosił błąd sprzętowy przez rejestry machine-check i istnieje rekord błędu do odczytania, tu żadnego rekordu nie ma — rdzeń po prostu zamilkł, a system wywnioskował awarię z braku odpowiedzi. Od THREAD_STUCK_IN_DEVICE_DRIVER (0xEA) różni się tym, że tamten dotyczy wyłącznie zawieszonego sterownika karty graficznej, a nie rdzenia procesora. Unikalny dla 0x101 jest też czwarty parametr błędu: indeks konkretnego logicznego rdzenia, który przestał odpowiadać. Żaden inny kod z tej listy nie daje takiego wskazania i to na nim opiera się cała praktyczna diagnostyka — łącznie z rozpoznaniem degradacji Vmin Shift w procesorach Intel 13. i 14. generacji, której ta strona jest w naszej bazie miejscem docelowym.

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

  • Nie zostawiaj podkręcenia „na stałe" bez okresowej weryfikacji. Ustawienie stabilne przy zakupie przestaje być stabilne po roku, bo krzem się starzeje, a pasta termoprzewodząca traci właściwości.
  • Traktuj XMP i EXPO jak przetaktowanie, bo nim są. Jeśli komputer ma być bezawaryjny (praca, serwer, stacja montażowa), pozostaw pamięć na częstotliwości bazowej albo zweryfikuj profil kilkugodzinnym testem przed oddaniem maszyny do pracy.
  • Aktualizuj BIOS raz na pół roku, sprawdzając w opisie wersji, czy zawiera nowszy mikrokod procesora lub AGESA. To jedyna droga, jaką producent procesora może naprawić błędy zarządzania napięciem.
  • Utrzymuj temperaturę procesora poniżej 85 °C pod obciążeniem. Napięcie potrzebne rdzeniowi rośnie z temperaturą, a wysoka temperatura przy wysokim napięciu to dokładnie ta kombinacja, która degraduje obwód zegarowy w rdzeniu.
  • Czyść komputer z kurzu raz do roku i wymieniaj pastę termoprzewodzącą co 2-3 lata, w laptopach częściej.
  • Dobieraj zasilacz z zapasem mocy około 30% ponad sumaryczny pobór i wymieniaj go po 6-8 latach pracy, nawet jeśli działa. Podłączaj procesor osobnymi przewodami EPS, nie rozgałęzieniem.
  • Ogranicz oprogramowanie RGB i monitorujące do jednego pakietu. Każdy z tych programów instaluje własny sterownik odczytujący rejestry procesora — kilka naraz to gotowy przepis na konflikt na poziomie jądra.
  • Włącz zapisywanie małych zrzutów pamięci i nie kasuj zawartości C:\Windows\Minidump. Bez tych plików ustalenie, który rdzeń się zawiesza, jest niemożliwe.
  • Jeśli stosujesz undervolt przez Curve Optimizer, testuj go narzędziem obciążającym pojedyncze rdzenie (CoreCycler), a nie testem wszystkich rdzeni naraz — inaczej sprawdzasz nie ten scenariusz, w którym undervolt zawodzi.

Pytania i odpowiedzi

Nie od razu. W większości przypadków, jakie widzimy w serwisie, wystarcza cofnięcie zmian w BIOS (przetaktowanie, XMP/EXPO, undervolt) albo aktualizacja mikrokodu. Za uszkodzonym procesorem przemawia dopiero sytuacja, w której komputer pracuje na ustawieniach domyślnych, z aktualnym BIOS-em, sprawnym zasilaczem i chłodzeniem, a błąd nadal wraca — szczególnie gdy kolejne awarie wskazują ten sam indeks rdzenia w czwartym parametrze błędu.

Z czwartego parametru błędu. Uruchom PowerShell jako administrator i wpisz Get-WinEvent -FilterHashtable @{LogName='System'; Id=1001} -MaxEvents 20 | Format-List TimeCreated, Message. W treści zobaczysz wiersz zaczynający się od „The bugcheck was: 0x00000101" i cztery liczby w nawiasie — ostatnia to indeks zawieszonego rdzenia. Zbierz dane z kilku awarii: powtarzalny indeks wskazuje na konkretny rdzeń, losowe indeksy na problem globalny (zasilanie, temperatura, mikrokod).

Ten kod jest jednym z typowych objawów tej wady, ale nie jedynym możliwym wyjaśnieniem. Intel potwierdził, że w tych generacjach zbyt wysokie napięcia degradowały obwód zegarowy wewnątrz rdzeni, i wydał poprawki mikrokodu 0x12B oraz 0x12F, a także przedłużył gwarancję o dwa lata. Dla procesorów pudełkowych daje to pięć lat od zakupu i zgłoszenie idzie do Intela; procesory tray i te montowane fabrycznie w gotowych komputerach obsługuje producent systemu. Program obejmuje imienną listę modeli — sprawdź na niej swój procesor. Jeśli po aktualizacji BIOS-u do wersji z mikrokodem 0x12F i pracy na profilu „Intel Default Settings" błędy nadal występują, masz podstawy do reklamacji.

Dysku praktycznie nigdy — awaria dysku daje inne kody błędów. Pamięć bywa pośrednio winna: niestabilny profil XMP/EXPO obciąża kontroler pamięci wbudowany w procesor i przy zbyt wysokim FCLK lub zbyt niskim napięciu SoC rdzeń potrafi się zawiesić. Dlatego wyłączenie profilu pamięci jest jednym z pierwszych kroków, mimo że sam błąd dotyczy procesora. Klasyczne błędy pamięci częściej dają jednak kody typu MEMORY_MANAGEMENT czy PAGE_FAULT_IN_NONPAGED_AREA.

Zwykle nie, i zwykle jest stratą czasu. Warto ją rozważyć tylko wtedy, gdy podejrzewasz konflikt sterowników niskiego poziomu (narzędzia RGB, monitoringu, wirtualizacja) — a wtedy szybciej sprawdzisz to czystym rozruchem przez msconfig. Jeśli błąd wynika z napięcia, temperatury albo degradacji rdzenia, świeży system zachowa się identycznie.

To bardzo typowy i diagnostycznie cenny obraz. Przy niskim obciążeniu pojedyncze rdzenie osiągają najwyższe zegary i wymagają najwyższego napięcia, a jednocześnie system usypia i wybudza rdzenie ze stanów C. Jeśli masz ustawiony undervolt (Curve Optimizer, Intel XTU) — cofnij go w pierwszej kolejności. Jeśli nie masz, przetestuj wyłączenie stanów bezczynności poleceniem powercfg opisanym w rozwiązaniach; potwierdzenie mechanizmu kieruje diagnostykę na BIOS i zarządzanie energią.

Rzadziej niż w komputerach stacjonarnych, bo laptopy nie są podkręcane. Gdy się pojawia, przyczyną bywa zwykle przegrzewanie z powodu zapchanego układu chłodzenia, zużyta bateria lub zastępczy zasilacz o zbyt małej mocy (napięcie zapada przy skoku poboru), albo uszkodzenie sekcji zasilania procesora na płycie. Procesor jest wlutowany, więc diagnostyka idzie w stronę chłodzenia i pomiarów zasilania, a nie wymiany podzespołu.

Pojedyncze wystąpienie po aktualizacji sterownika, zmianie ustawień lub przy nietypowo wysokiej temperaturze w pokoju może pozostać incydentem. Zapisz sobie datę, upewnij się, że system zapisuje minidumpy, i obserwuj. Powtórki w odstępie kilku dni, zwłaszcza z tym samym indeksem rdzenia, oznaczają narastający problem sprzętowy — i wtedy warto zareagować, zanim procesor będzie na gwarancji o rok krócej.

Doktor Komputer · Bielsko-Biała

Warsztat serwisowy działający od 2009. Tysiące diagnoz BSOD rocznie. Artykuł zweryfikowany w oparciu o dokumentację Microsoft Learn.

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ń.

Pon-Czw 10-18 · Pt 10-16 · ul. 3 Maja 25, Bielsko-Biała