Co najczęściej powoduje ten błąd
Typowy rozkład przyczyn dla memory management — od najczęstszych do rzadszych.
- 32%
Niestabilna pamięć pracująca na profilu XMP/EXPO lub zbyt agresywnych opóźnieniach — kontroler pamięci przy taktowaniu spoza specyfikacji sporadycznie odczytuje pojedynczy bit błędnie. Jeśli trafi to na stronę zawierającą tablicę stron albo wpis bazy PFN, uszkodzeniu ulegają nie dane użytkownika, lecz mapa pamięci, a menedżer pamięci wykrywa rozjazd dopiero przy najbliższym przeglądzie struktur — często wiele sekund po samym przekłamaniu
- 24%
Fizycznie wadliwy moduł RAM, utleniony styk krawędziowy lub uszkodzone gniazdo DIMM — komórka gubiąca ładunek daje ten sam skutek co niestabilny zegar. Charakterystyczne jest to, że kod błędu zmienia się między restartami (raz ten, raz PFN_LIST_CORRUPT, raz KMODE_EXCEPTION_NOT_HANDLED), bo o rodzaju awarii decyduje to, która struktura akurat leżała w wadliwym obszarze
- 18%
Sterownik uszkadzający struktury menedżera pamięci — typowe wzorce to dwukrotne wywołanie MmUnlockPages na tej samej liście MDL (licznik referencji strony schodzi poniżej zera), zapis do bufora puli już zwolnionej albo zbudowanie MDL dla zakresu wirtualnego, który nie jest zablokowany w pamięci fizycznej. Najczęściej dotyczy sterowników filtrujących pakietów bezpieczeństwa i VPN, starszych sterowników sieciowych oraz narzędzi do monitoringu i podkręcania
- 11%
Przekłamanie danych na drodze do pliku wymiany — Arg1 równe 0x3f oznacza, że strona wczytana z pagefile.sys miała inną sumę kontrolną niż w chwili zapisu: odczyt formalnie się powiódł, ale wróciły inne bajty. Odpowiada za to zwykle firmware dysku SSD, sterownik NVMe lub RAID albo kontroler i okablowanie
- 9%
Niestabilne zasilanie lub taktowanie procesora — zbyt głęboki undervolt (Curve Optimizer, PBO), podkręcony ring/uncore, za niskie VSOC lub VDD2 przy DDR5. Rdzeń wylicza wtedy adres błędnie i zapis trafia poza przeznaczoną strukturę, co menedżer pamięci wykrywa jako uszkodzenie własnych tablic
- 6%
Uszkodzony obraz systemu lub konflikt po aktualizacji — przerwana aktualizacja funkcji, pozostałości po niepełnej deinstalacji pakietu bezpieczeństwa, sterownik magistrali przeniesiony razem z obrazem na inny sprzęt. To najmniejsza grupa i warto ją podejrzewać dopiero wtedy, gdy testy pamięci są czyste, a profil XMP wyłączony
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ąć.
- Nowo złożony komputer na DDR5 z włączonym profilem EXPO 6400 przechodzi wszystkie testy syntetyczne, ale co kilka dni pokazuje niebieski ekran przy przeglądarce z kilkudziesięcioma otwartymi kartami.
- Laptop po samodzielnym rozszerzeniu pamięci o dokupioną kość innego producenta zaczyna się wysypywać przy montażu wideo i pracy na dużych plikach, a przy pojedynczym module działa bez zarzutu.
- Komputer stabilny przez dwa lata zaczyna sypać niebieskimi ekranami zaraz po aktualizacji BIOS, która przywróciła ustawienia domyślne i sama włączyła agresywny profil pamięci.
- Stacja robocza z dyskiem NVMe pokazuje ten błąd z Arg1 równym 0x3f po każdym dłuższym renderingu, a w dzienniku systemu pojawiają się wpisy o uszkodzonych stronach pliku wymiany.
- Po instalacji drugiego pakietu bezpieczeństwa obok już zainstalowanego klienta VPN system zaczyna zatrzymywać się przy usypianiu i wybudzaniu, zawsze w tym samym momencie.
- Komputer do gier z procesorem Intel Core i9 13. lub 14. generacji na płycie z fabrycznym BIOS-em zaczyna po kilku miesiącach losowo się zatrzymywać, za każdym razem z innym kodem błędu.
- Serwer plików z pamięcią ECC zatrzymuje się raz na kilka tygodni, a licznik skorygowanych błędów pamięci w panelu IPMI systematycznie rośnie.
- Komputer działa bez zarzutu po zimnym starcie, ale zawiesza się lub restartuje po wybudzeniu ze snu — objaw typowy dla niepełnego treningu pamięci DDR5.
Jak naprawić — rozwiązania krok po kroku
Zacznij od pierwszego — to najprostsze i najczęściej działa. Jeśli nie pomoże, idź dalej.
Odczytaj parametr Arg1 — on wyznacza całą dalszą ścieżkę
- Sprawdź, czy Windows w ogóle zapisuje zrzuty: Win+R, wpisz sysdm.cpl, zakładka Zaawansowane, sekcja Uruchamianie i odzyskiwanie, przycisk Ustawienia, pole „Zapisywanie informacji o debugowaniu" ustaw na „Mały zrzut pamięci (256 KB)".
- Pliki znajdziesz w katalogu C:\Windows\Minidump pod nazwami typu 080426-9328-01.dmp. Jeśli katalog jest pusty, kolejny niebieski ekran dopiero wygeneruje materiał do analizy.
- Najszybciej: BlueScreenView (NirSoft) albo WhoCrashed — pokazują wszystkie cztery parametry bez instalowania debuggera. Dokładniej: WinDbg ze Sklepu Microsoft, File → Open dump file, potem polecenie !analyze -v i linia zaczynająca się od Arg1.
- GAŁĄŹ PAMIĘCIOWA — Arg1 równe 0x41790 (uszkodzona strona tablicy stron), 0x41792 (uszkodzony wpis PTE), 0x403 lub 0x404 (rozjazd między PTE a bazą PFN), 0x411, 0x41202, 0x41287, 0x9696. Przy 0x403 dokumentacja Microsoftu podaje dodatkową wskazówkę: jeśli parametry 3 i 4 różnią się dokładnie jednym bitem, to niemal na pewno przekłamanie w pamięci. Uwaga — ta heurystyka dotyczy wyłącznie 0x403; przy 0x404 parametry opisują co innego (oczekiwany PTE, zawartość PTE, PTE z bazy PFN) i reguła jednego bitu tam nie obowiązuje. Idź do kroków o profilu XMP i teście pamięci.
- GAŁĄŹ DYSKOWA — Arg1 równe 0x3f. To jedyny podkod kierujący na dysk: strona wróciła z pliku wymiany z inną sumą kontrolną, niż miała przy zapisie. Idź do kroku o pliku wymiany i nośniku.
- GAŁĄŹ KOMPRESJI PAMIĘCI — Arg1 równe 0x6001 oznacza uszkodzenie prywatnego obszaru pamięci komponentu magazynu skompresowanych stron. To dokładnie ten sam komponent, którego dotyczy błąd UNEXPECTED_STORE_EXCEPTION — przejdź na jego stronę, opisaliśmy tam pełną procedurę, łącznie z testem rozstrzygającym.
- GAŁĄŹ STEROWNIKOWA — Arg1 równe 0x1236 lub 0x1240 (błąd sterownika przy obsłudze listy MDL), 0x1233 (sterownik próbował odwzorować stronę fizyczną, która nie była zablokowana — to inny błąd niż dwa poprzednie, choć skutek podobny), 0x5200 (zapis do puli już zwolnionej, czyli klasyczny write-after-free w sterowniku), 0x3470 (uszkodzony stos jądra na liście wolnych). Idź prosto do Driver Verifiera — testowanie pamięci i sprawdzanie dysku niczego tu nie wniesie.
- PODKODY WYCOFANE — jeśli w zrzucie zobaczysz 0x5003, 0x41201, 0x41284 albo 0x41793, sprawdź wersję systemu. Microsoft oznacza je jako używane w poprzednich wydaniach Windows i na aktualnych Windows 10 oraz 11 praktycznie nie występują. Poradniki, które je wymieniają, są przepisywane z dokumentacji sprzed lat.
- Zwróć uwagę na pole MODULE_NAME. Przy tym kodzie wskazuje ono zwykle ntoskrnl.exe albo memory_corruption i nie identyfikuje sprawcy — to normalne i nie jest błędem analizy.
Gałąź pamięciowa: wyłącz profil XMP/EXPO
- Wejdź do BIOS/UEFI klawiszem Del lub F2 zaraz po włączeniu komputera (na laptopach zwykle F2 albo F10).
- Znajdź ustawienie profilu pamięci: ASUS — Ai Tweaker → Ai Overclock Tuner; MSI — OC → Extreme Memory Profile; Gigabyte — Tweaker → Extreme Memory Profile; ASRock — OC Tweaker → DRAM Profile Configuration.
- Ustaw wartość Disabled lub Auto. Pamięć zejdzie na taktowanie JEDEC (przy DDR5 zwykle 4800 MT/s). Zapisz klawiszem F10.
- Używaj komputera normalnie przez 3 do 5 dni. Brak niebieskich ekranów oznacza, że winny jest profil lub kontroler pamięci, a nie same kości.
- Jeśli w płycie są cztery moduły DDR5, spróbuj pracy na dwóch w gniazdach A2 i B2 — kontroler AM5 przy czterech kościach oficjalnie obsługuje tylko 3600 do 4800 MT/s.
- Wyczyść pamięć CMOS (zworka CLR_CMOS albo wyjęcie baterii na 5 minut przy odłączonym zasilaczu). Częściowe treningi pamięci po hibernacji potrafią utrwalać niestabilne ustawienia, których zwykły restart nie kasuje.
- O ręcznym strojeniu napięć uczciwie: jeśli nie wiesz, co robi VDDQ ani VDDCR_SOC, zostaw pamięć na JEDEC i nie zmieniaj napięć. Na platformie AM5 zawyżone napięcie SoC trwale uszkadzało procesory i płyty — to nie jest ustawienie do eksperymentowania metodą prób i błędów. Bezpieczna droga bez znajomości tematu to zejście profilem o jeden stopień niżej (na przykład z 6400 na 6000, potem na 5600) przy niezmienionych napięciach; resztę zostaw serwisowi.
Gałąź pamięciowa: MemTest86 i metoda eliminacji
- Pobierz MemTest86 ze strony memtest86.com, rozpakuj i uruchom imageUSB.exe, żeby nagrać pendrive.
- W BIOS wyłącz Secure Boot albo użyj wersji podpisanej, ustaw rozruch z pendrive'a.
- Uruchom pełny przebieg, czyli 4 passes. Przy 32 GB trwa to od 4 do 10 godzin — zostaw na noc.
- Jakikolwiek błąd, choćby pojedynczy, oznacza pamięć lub kontroler do wymiany albo do przestrojenia. Zero błędów NIE wyklucza problemu z pamięcią, bo MemTest obciąża układ inaczej niż realna praca systemu.
- Wbudowana mdsched.exe (Diagnostyka pamięci Windows) wykonuje ograniczony zestaw testów w krótkim czasie i regularnie przepuszcza usterki wykrywane przez MemTest86 dopiero w drugim czy trzecim przebiegu. Jej komunikat o braku błędów nie ma wartości rozstrzygającej.
- Jeśli MemTest zgłasza błędy, testuj po jednym module i po jednym gnieździe. Wynik typu „kość A w gnieździe 2 daje błędy, kość B w tym samym gnieździe jest czysta" wskazuje na kość. Wynik „obie kości w gnieździe 2 dają błędy, a w gnieździe 4 nie" wskazuje na gniazdo lub kontroler.
- Wyjmij i włóż moduły ponownie, dociskając aż zatrzaski klikną. Styki krawędziowe przetrzyj bezwodnym alkoholem izopropylowym.
- Uzupełniająco uruchom w Windows TestMem5 z konfiguracją anta777 albo y-cruncher w trybie VST — łapią niestabilności, które MemTest86 przepuszcza.
Gałąź sterownikowa: Driver Verifier z Pulą specjalną
- Najpierw utwórz punkt przywracania systemu i upewnij się, że masz dostęp do środowiska odzyskiwania (Shift wciśnięty przy poleceniu Uruchom ponownie). Punkt przywracania to nie kopia danych — jeśli podejrzewasz również dysk, zrób najpierw backup, bo Verifier celowo zwiększa liczbę twardych zatrzymań.
- Win+R, wpisz verifier, wybierz „Utwórz ustawienia niestandardowe (dla programistów)", następnie „Wybierz poszczególne ustawienia z pełnej listy".
- Zaznacz: Pula specjalna, Wymuszanie sprawdzania puli, Śledzenie puli, Wykrywanie zakleszczeń, Sprawdzanie we/wy oraz Weryfikacja DMA. Na pierwszym przebiegu NIE zaznaczaj Symulacji braku zasobów ani Nadzoru zgodności DDI — generują fałszywe trafienia.
- Wybierz „Automatycznie wybierz niepodpisane sterowniki". Jeśli lista okaże się pusta, wybierz „Wybierz nazwy sterowników z listy" i zaznacz wszystko, co nie pochodzi od Microsoft Corporation.
- Uruchom ponownie i pracuj normalnie przez 24 do 48 godzin. Verifier celowo powoduje niebieski ekran w momencie wykrycia naruszenia, a nowy zrzut wskaże już konkretny plik .sys.
- Wyłączenie: verifier /reset w wierszu polecenia administratora i restart.
- Jeśli po włączeniu Verifiera system nie startuje: przerwij uruchamianie przyciskiem zasilania trzy razy z rzędu, wejdź w Rozwiązywanie problemów → Opcje zaawansowane → Wiersz polecenia i wykonaj verifier /reset. Alternatywnie to samo polecenie w trybie awaryjnym.
- Sterownik wskazany przez Verifier zaktualizuj wersją ze strony producenta sprzętu. Jeśli nowszej nie ma, odinstaluj urządzenie lub program. Sterownik karty graficznej usuwaj programem DDU w trybie awaryjnym, bo zwykła reinstalacja zostawia stare pliki.
Gałąź dyskowa: plik wymiany i nośnik
- Otwórz Podgląd zdarzeń (eventvwr.msc) → Dzienniki systemu Windows → System i poszukaj komunikatu „Memory manager detected N instance(s) of corrupted pagefile page(s)". To bezpośrednie potwierdzenie, że dane wracają z dysku przekłamane.
- Sprawdź stan nośnika programem CrystalDiskInfo. Przy dyskach NVMe zwróć uwagę na atrybuty Media and Data Integrity Errors oraz Percentage Used; przy SATA na Reallocated Sector Count (05), Current Pending Sector (C5) i Uncorrectable Sector Count (C6).
- Zanim uruchomisz chkdsk: jeśli SMART pokazuje ostrzeżenia albo dysk zachowuje się nietypowo (znika i wraca, system zawiesza się na kilkadziesiąt sekund), najpierw zrób kopię danych lub obraz dysku. Skan powierzchni to godziny ciągłego obciążenia i na słabnącym nośniku potrafi go dobić — a naprawa struktur zapisuje na wolumin i przy uszkodzonym dysku zamienia problem z odczytem w utratę katalogu plików.
- Mając kopię: chkdsk C: /f, a parametr /r dodawaj wyłącznie przy dysku talerzowym o potwierdzonym dobrym stanie.
- Odbuduj plik wymiany: uruchom SystemPropertiesAdvanced.exe → Wydajność → Ustawienia → Zaawansowane → Zmień w sekcji Pamięć wirtualna. Odznacz automatyczne zarządzanie, wybierz Brak pliku wymiany, zatwierdź, uruchom ponownie komputer, po restarcie wróć i ustaw Rozmiar zarządzany przez system, znowu uruchom ponownie.
- Zaktualizuj firmware dysku SSD narzędziem producenta: Samsung Magician, WD Dashboard, Crucial Storage Executive, Kingston SSD Manager.
- Jeśli dysk jest podłączony przez adapter M.2, przedłużacz PCIe albo taśmę SATA — wymień okablowanie. Przekłamania na złym połączeniu to częsty i tani do usunięcia sprawca.
- Uruchom DISM /Online /Cleanup-Image /RestoreHealth, a po jego zakończeniu sfc /scannow. Rzadko rozwiązuje to ten błąd, ale wyklucza uszkodzony obraz systemu i nic nie kosztuje.
Zaktualizuj BIOS/UEFI, sterowniki chipsetu i firmware
- Sprawdź aktualną wersję: Win+R, wpisz msinfo32, spójrz na pozycję „Wersja/data systemu BIOS" oraz model płyty głównej.
- Porównaj z wersją dostępną na stronie producenta płyty lub laptopa. Czytaj listę zmian — producenci wprost opisują poprawki stabilności pamięci.
- Dla platformy AM5 szukaj wpisów o nowej wersji AGESA. Wydania 1.2.0.x i nowsze naprawiły dużą część problemów z treningiem DDR5, które objawiały się właśnie tym błędem.
- Jeśli masz procesor Intel Core 13. lub 14. generacji, a awarie narastają z miesiąca na miesiąc, sprawdź stronę CLOCK_WATCHDOG_TIMEOUT — opisaliśmy tam degradację Vmin Shift, wymagane wersje mikrokodu i zasady przedłużonej gwarancji Intela. Tu wystarczy zasada: BIOS z mikrokodem 0x12B lub nowszym.
- Zainstaluj aktualny pakiet chipsetu: AMD Chipset Software albo Intel Chipset Device Software, ze strony producenta procesora, nie z Windows Update.
- Po aktualizacji BIOS ustawienia wracają do domyślnych. Sprawdź, czy profil pamięci nie włączył się automatycznie na wartościach, które wcześniej były niestabilne.
Eliminacja sprzętowa i ocena opłacalności naprawy
- Uruchom komputer z jednym modułem RAM w gnieździe zalecanym przez instrukcję płyty (zwykle A2, czyli drugie od procesora), na ustawieniach domyślnych BIOS.
- Wyłącz wszystkie mechanizmy podkręcania: PBO, Curve Optimizer, XMP/EXPO, ręczne napięcia. Odinstaluj Ryzen Master, Intel XTU i narzędzia do podkręcania kart graficznych — ich sterowniki działają w jądrze.
- Odłącz nieużywane urządzenia: dodatkowe dyski, karty rozszerzeń, huby USB, zewnętrzne karty dźwiękowe. Sterownik odłączonego urządzenia przestaje być podejrzanym.
- Sprawdź zasilanie i temperatury programem HWiNFO64, zakładka Sensors. Spadki na liniach 12 V i 3,3 V pod obciążeniem oraz temperatury sekcji zasilania powyżej 100 °C dają objawy nie do odróżnienia od wadliwej pamięci.
- Jeśli błędy występują tylko po wybudzeniu ze snu, sprawdź, czy problem znika po wyłączeniu trybów uśpienia i zejściu pamięci na JEDEC. Częściowe treningi DDR5 przy wybudzaniu to znane źródło niestabilności.
- Instalacja czystego systemu na zapasowym dysku jest szybkim testem rozstrzygającym. Jeśli błąd wraca na świeżym Windows bez dodatkowych sterowników, przyczyna jest sprzętowa.
- W laptopach z pamięcią lutowaną (LPDDR4X, LPDDR5) wymiana modułu nie wchodzi w grę. Pozostaje test płyty w serwisie, a przy potwierdzonej wadzie kontrolera lub kości — wymiana płyty głównej, co przy starszym sprzęcie bywa nieopłacalne w stosunku do jego wartości.
Kiedy to przestaje być kwestią oprogramowania
Jeśli błąd wraca po czystej instalacji Windows albo pojawia się losowo pod obciążeniem, przyczyną jest zwykle wadliwa kość pamięci — nie system. Potwierdzi to test MemTest86 puszczony na kilka godzin; pojedynczy błąd w teście wystarczy, żeby uznać pamięć za uszkodzoną. Jeśli test wychodzi czysto, a błąd wraca, problem leży zwykle w gnieździe pamięci albo w sekcji zasilania płyty.
Czym ten błąd różni się od podobnych
Najbliższe w bazie są PAGE_FAULT_IN_NONPAGED_AREA (0x50) i KERNEL_DATA_INPAGE_ERROR (0x7A), ale mechanizm każdego z tych trzech błędów jest inny. Przy 0x50 ktoś — sterownik albo kod jądra — sięgnął pod konkretny adres wirtualny, który nie ma poprawnego odwzorowania; system zna zarówno ten adres, jak i instrukcję, która go dotknęła, więc stos wywołań zwykle wskazuje winowajcę wprost. Przy 0x7A operacja odczytu strony z dysku zakończyła się błędem i sterownik nośnika zwrócił kod statusu — awaria jest zgłoszona wprost przez sprzęt. Przy MEMORY_MANAGEMENT nikt nie sięgnął pod zły adres i żadna operacja nie zwróciła błędu: to menedżer pamięci podczas własnej rutynowej pracy porównał swoje zapisy i stwierdził, że się nie zgadzają. To wewnętrzny audyt spójności, a nie naruszenie dostępu. Konsekwencja praktyczna jest bardzo konkretna: stos wywołań pokazuje niemal wyłącznie funkcje nt!Mm* i nie identyfikuje sprawcy, bo uszkodzenie powstało wcześniej — cała diagnostyka opiera się na wartości Arg1, która przy 0x50 i 0x7A nie pełni tej roli w ogóle. Osobnym przypadkiem jest Arg1 równe 0x3f, które pozornie zbliża ten kod do 0x7A, bo też dotyczy pliku wymiany. Różnica pozostaje wyraźna: przy 0x7A odczyt z dysku się nie udał, a tutaj odczyt się udał, tylko wróciły inne bajty niż zapisano i wykryła to dopiero suma kontrolna Windows — sam nośnik nie zgłosił żadnego problemu. Wobec BAD_POOL_HEADER (0x19) i BAD_POOL_CALLER (0xC2) różnica leży w tym, co jest audytowane: tamte pilnują metadanych alokatora puli, czyli nagłówka pojedynczego bloku pamięci i poprawności żądania, a ten kod pilnuje globalnej mapy pamięci — tablic stron i bazy PFN. Uszkodzony nagłówek bloku puli dotyczy jednej alokacji, rozjazd PTE z bazą PFN dotyczy całego odwzorowania pamięci fizycznej. Wobec IRQL_NOT_LESS_OR_EQUAL i KMODE_EXCEPTION_NOT_HANDLED różnica jest taka jak między alarmem a sekcją zwłok: tamte kody powstają w momencie, gdy błędna operacja jest wykonywana, więc winowajca stoi na stosie. Tutaj system wykrywa skutek, często wiele sekund po fakcie. Dlatego przy tych dwóch kodach zaczyna się od odczytania stosu, a przy tym — od odczytania Arg1 i wyboru gałęzi. Wobec dwóch nowszych sąsiadów: KERNEL_SECURITY_CHECK_FAILURE (0x139) też jest kontrolą spójności, ale wbudowaną w sterowniki i jądro i wyzwalaną natychmiast przez instrukcję __fastfail, a diagnostykę prowadzi się tam przez porównanie powtarzalności między kolejnymi zrzutami. UNEXPECTED_STORE_EXCEPTION (0x154) obejmuje wyłącznie magazyn skompresowanych stron i jest w tej bazie właścicielem tego tematu — jeśli twój Arg1 to 0x6001, właściwą stroną jest tamta, nie ta.
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
- Po każdym włączeniu profilu XMP/EXPO przetestuj stabilność: minimum 4 przebiegi MemTest86 plus godzina TestMem5 albo y-cruncher. Profil, który po prostu wystartował, nie jest jeszcze profilem stabilnym.
- Kupując pamięć do platformy AM5 wybieraj zestawy z certyfikatem EXPO i trzymaj się dwóch modułów. Profile XMP powyżej 6000 MT/s na procesorach AMD w większości przypadków wymagają ręcznego strojenia napięć.
- Nie mieszaj modułów z różnych zestawów, nawet o identycznych parametrach na naklejce. Kości dobierane parami przechodzą wspólny trening, dokupiona pojedyncza sztuka bywa niestabilna przy tych samych ustawieniach.
- Utrzymuj aktualny BIOS i sterownik chipsetu, szczególnie na płytach DDR5 z pierwszego roku produkcji danej platformy — poprawki treningu pamięci trafiają wyłącznie tą drogą.
- Aktualizuj firmware dysku SSD narzędziem producenta. Kilka popularnych serii miało błędy powodujące przekłamania przy odczycie, widoczne później jako awarie pliku wymiany.
- Nie instaluj równolegle dwóch pakietów antywirusowych ani dwóch klientów VPN. Ich sterowniki filtrujące wpinają się w te same ścieżki jądra i wzajemnie psują sobie struktury pamięci.
- Włącz zapisywanie małych zrzutów pamięci, zanim wystąpi awaria (sysdm.cpl → Uruchamianie i odzyskiwanie). Bez tego pierwszy niebieski ekran nie zostawi materiału do analizy, a przy tym kodzie zrzut to jedyne źródło informacji o tym, którą gałąź diagnostyki wybrać.
- W stacjach roboczych i serwerach z pamięcią ECC kontroluj licznik skorygowanych błędów w BIOS lub IPMI. Rosnąca liczba korekcji zapowiada awarię modułu z kilkutygodniowym wyprzedzeniem.
- Raz w roku przedmuchaj wnętrze obudowy i sprawdź, czy moduły pamięci siedzą do końca w gniazdach. Kurz i wilgoć utleniają styki krawędziowe, a luźny moduł daje dokładnie te same objawy co uszkodzony.
Pytania i odpowiedzi
Nie. Nazwa wskazuje moduł Windows, który wykrył problem, a nie jego przyczynę. W praktyce serwisowej mniej więcej połowa przypadków to pamięć albo jej ustawienia, ale pozostałe to sterowniki, przekłamania na drodze do pliku wymiany i niestabilne zasilanie procesora. Dlatego pierwszym krokiem jest odczytanie parametru Arg1 ze zrzutu, a nie zamawianie nowych kości — ten sam kod przy Arg1 równym 0x1236 oznacza błąd sterownika i testowanie pamięci niczego tam nie wykaże.
Nie. Narzędzie mdsched.exe wykonuje ograniczony zestaw wzorców testowych w krótkim czasie i regularnie przepuszcza usterki, które MemTest86 znajduje dopiero w drugim czy trzecim przebiegu. Traktuj jego wynik jako informację o braku rażącego uszkodzenia i nic więcej. Rozstrzygający jest dopiero pełny, kilkugodzinny test spoza systemu.
Bo w chwili zatrzymania systemu pracował menedżer pamięci, który jest częścią jądra. Uszkodzenie struktur powstało wcześniej, czasem kilka minut przed awarią, a kod, który je spowodował, dawno zniknął ze stosu. To odróżnia ten błąd od większości innych niebieskich ekranów i właśnie dlatego do wskazania winnego sterownika potrzebny jest Driver Verifier, a nie sama analiza zrzutu.
Niekoniecznie. Częściej problem leży po stronie kontrolera pamięci w procesorze albo treningu płyty, a same moduły są w pełni sprawne w swojej nominalnej specyfikacji JEDEC. Sprawdź nowszy BIOS i spróbuj profilu o stopień niższego. Wymianę modułów rozważaj dopiero, gdy MemTest86 zgłasza błędy również przy wyłączonym profilu.
Tylko w części przypadków — tam, gdzie przyczyną jest uszkodzony obraz systemu albo konfliktujące sterowniki, czyli w niewielkim odsetku zgłoszeń. Jeśli przyczyna jest sprzętowa, błąd wróci na świeżej instalacji. Właśnie dlatego czysty system na zapasowym dysku jest bardzo dobrym testem diagnostycznym, zanim potraktujesz go jako naprawę.
Prawie zawsze jedna. Gdy pamięć przekłamuje bity losowo, o wyświetlonym kodzie decyduje wyłącznie to, która struktura jądra akurat leżała w uszkodzonym obszarze. Zmienność kodów między restartami jest sama w sobie mocną przesłanką za problemem sprzętowym z pamięcią lub jej kontrolerem, a nie za pojedynczym sterownikiem.
Kieruje diagnostykę na dysk, nie na RAM. Ten podkod oznacza, że strona wczytana z pliku wymiany miała inną sumę kontrolną niż w chwili zapisu: odczyt się powiódł, ale wróciły inne dane, a nośnik sam tego nie zgłosił jako błędu. Zacznij od firmware SSD, sterownika NVMe, sprawdzenia okablowania lub adaptera M.2 i odbudowy pliku wymiany.
Nie. Microsoft definiuje 0x5200 jako uszkodzenie strony na liście wolnych bloków puli, typowo w wyniku zapisu do już zwolnionej pamięci przez sterownik. To wskazanie na oprogramowanie, nie na nośnik — sprawdzanie SMART, kabli i firmware SSD będzie przy tym podkodzie stratą czasu. Właściwa ścieżka to Driver Verifier z Pulą specjalną. Uważaj też na poradniki wymieniające podkody 0x5003, 0x41201, 0x41284 i 0x41793: Microsoft oznacza je jako używane w starszych wydaniach Windows.
Bezpłatna wstępna diagnoza, czyli godzina pracy serwisanta, obejmuje odczyt zrzutów awaryjnych, sprawdzenie ustawień BIOS i szybki test pamięci. Jeśli objaw jest sporadyczny, potrzebne bywają wielogodzinne testy obciążeniowe i praca metodą eliminacji podzespołów — to już płatna diagnostyka. Naprawy tej klasy potrafią zająć 7 dni lub dłużej, a dokładny czas i koszt podajemy po ustaleniu, w którym podzespole leży problem.
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ń.