Co najczęściej powoduje ten błąd
Typowy rozkład przyczyn dla unexpected store exception — od najczęstszych do rzadszych.
- 35%
Degradujący się dysk SSD lub HDD — wirtualna część magazynu kompresji leży w pliku pagefile.sys, więc gdy blok NAND lub sektor zwraca dane z błędem albo odczyt w ogóle się nie kończy, Store Manager dostaje STATUS_IN_PAGE_ERROR (0xC0000006) w środku rozpakowywania strumienia Xpress. Na SSD objawia się to rosnącą liczbą nieskorygowanych błędów odczytu i przekroczeń limitu czasu, a nie klasycznymi bad sectorami znanymi z dysków talerzowych
- 20%
Awaria na poziomie kontrolera i łącza, a nie samego nośnika — błąd firmware NVMe (udokumentowany przypadek Host Memory Buffer w Windows 11 24H2 na dyskach bez własnego DRAM), sterownik Intel RST/VMD zatrzymujący żądania I/O, agresywne stany oszczędzania energii PCIe (ASPM L1.2), przegrzany moduł M.2 albo luźny kabel SATA. Żądanie stronicowania nie wraca w czasie, sterownik resetuje urządzenie (Event ID 129), a magazyn zgłasza wyjątek
- 18%
Niestabilna pamięć RAM — skompresowane strony leżą w pamięci fizycznej, w zestawie roboczym procesu MemCompression, więc jeden przekłamany bit sprawia, że strumień Xpress przestaje być poprawnym strumieniem i dekompresja rzuca wyjątkiem naruszenia dostępu (0xC0000005). Typowe po włączeniu profilu XMP/EXPO, po dołożeniu kości od innego producenta albo przy jednej wadliwej kości
- 10%
Sterowniki filtrujące innych producentów w ścieżce dyskowej — minifiltry antywirusów, oprogramowanie do backupu i klonowania, szyfrowanie dysku. Przechwytują żądania stronicowania i przy błędzie własnej logiki zwracają porażkę albo przetrzymują IRP, co dla Store Managera jest nie do odróżnienia od awarii nośnika
- 8%
Uszkodzony plik stronicowania lub metadane NTFS po nagłym zaniku zasilania, przy włączonym Szybkim uruchamianiu (hybrydowe zamykanie zostawia stan systemu w hiberfil.sys) albo w konfiguracji dual-boot, gdzie drugi system montuje wolumin NTFS do zapisu — magazyn odczytuje z pagefile.sys dane, które nie są tym, co sam tam wcześniej zapisał
- 6%
Uszkodzenie pamięci jądra przez zupełnie inny sterownik (GPU, chipset, oprogramowanie RGB lub monitorujące), który zapisuje poza swoim buforem i trafia w struktury magazynu — awaria ujawnia się w kontekście MemCompression, choć winowajca jest gdzie indziej, dlatego testy dysku i RAM wychodzą wtedy czysto
- 3%
Brak wolnego miejsca na dysku systemowym lub uszkodzone pliki systemowe po przerwanej aktualizacji — plik stronicowania nie ma jak się rozszerzyć albo sterownik magazynu ładuje się w wersji niespójnej z jądrem
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ąć.
- Laptop z 8 GB RAM i dyskiem NVMe bez własnego DRAM: niebieski ekran pojawia się przy kilkunastu kartach w przeglądarce i otwartym komunikatorze, czyli dokładnie wtedy, gdy Windows najintensywniej kompresuje pamięć.
- Komputer po aktualizacji do Windows 11 24H2 zaczyna się wywalać przy kopiowaniu dużych plików lub instalacji gry — typowe dla dysków WD Blue SN580/SN5000, WD Black SN770 i SanDisk Extreme M.2 bez aktualizacji firmware.
- Pięcioletni SSD SATA w laptopie: BSOD raz na kilka dni, w dzienniku systemu zdarzenia 51 i 153, w SMART rośnie Current Pending Sector.
- Komputer stacjonarny po włączeniu XMP na nowym zestawie pamięci: 0x154 przeplata się z MEMORY_MANAGEMENT i losowym zamykaniem aplikacji.
- Komputer firmowy z korporacyjnym antywirusem i agentem backupu — awarie zawsze w oknie nocnego skanowania.
- Laptop wywalający się kilkanaście sekund po wybudzeniu ze snu: dysk NVMe nie wraca w porę ze stanu oszczędzania energii L1.2, w logach zdarzenie 129 od stornvme.
- Komputer w dual-boot z Linuksem, gdzie wolumin Windows był montowany do zapisu przy włączonym Szybkim uruchamianiu — plik stronicowania i metadane NTFS rozjechały się ze stanem zapisanym w hiberfil.sys.
- Komputer po nagłym zaniku zasilania: pierwszy BSOD 0x154 pojawia się przy następnym uruchomieniu i wraca przy każdym większym obciążeniu pamięci.
Jak naprawić — rozwiązania krok po kroku
Zacznij od pierwszego — to najprostsze i najczęściej działa. Jeśli nie pomoże, idź dalej.
Zacznij od SMART i logów dysku, nie od naprawiania systemu
- Zainstaluj CrystalDiskInfo i sprawdź atrybuty: Reallocated Sectors Count (05), Current Pending Sector (C5), Uncorrectable Sector Count (C6), a dla NVMe — Media and Data Integrity Errors, Available Spare i Percentage Used.
- W PowerShell uruchomionym jako administrator: Get-PhysicalDisk | Select FriendlyName, MediaType, HealthStatus, OperationalStatus, a następnie Get-PhysicalDisk | Get-StorageReliabilityCounter | Format-List. Interesują cię ReadErrorsUncorrected, Wear i Temperature (cmdlet działa tylko z uprawnieniami administratora).
- Otwórz Podgląd zdarzeń (eventvwr.msc) → Dzienniki systemu Windows → System i przefiltruj po źródłach disk, stornvme, storahci, Ntfs. Kluczowe identyfikatory: 7 i 51 (błąd podczas operacji stronicowania), 153 (operacja I/O ponowiona), 129 (reset urządzenia przez sterownik).
- Szybciej z wiersza poleceń: wevtutil qe System /q:"*[System[(EventID=7 or EventID=51 or EventID=129 or EventID=153)]]" /c:30 /rd:true /f:text
- Wyniki decydują o dalszej kolejności: błędy w SMART lub wpisy 51/129/153 przenoszą całą diagnostykę na dysk. Czysty SMART nie zamyka sprawy — kontrolery NVMe potrafią nie raportować problemów z łączem — ale przesuwa podejrzenie na RAM i sterowniki.
Zabezpiecz dane, zanim uruchomisz narzędzia naprawcze
- Nie uruchamiaj chkdsk z parametrem /r ani /f na dysku, który już zwraca błędy odczytu. Pełny skan powierzchni (/r) to kilka godzin ciągłego obciążenia, ale również sama naprawa struktur (/f) zapisuje na wolumin i na słabnącym nośniku potrafi zamienić problem z odczytem w utratę katalogu plików.
- Skopiuj dane użytkownika na dysk zewnętrzny albo zrób obraz całego dysku: Macrium Reflect lub Clonezilla dla nośnika w umiarkowanym stanie, ddrescue z płyty startowej Linux dla dysku, który się już sypie.
- Jeśli system nie działa na tyle długo, żeby skopiować dane — wypnij dysk i podłącz go w innym komputerze albo przez adapter USB. Odczyt danych z dysku niesystemowego omija ścieżkę stronicowania, która wywołuje ten BSOD.
- Dopiero mając kopię, przechodź do testów i napraw, które obciążają nośnik.
Wyłącz kompresję pamięci jako test rozstrzygający
- PowerShell jako administrator: Get-MMAgent — sprawdź, czy MemoryCompression ma wartość True.
- Wykonaj Disable-MMAgent -MemoryCompression (skrót parametru: -mc) i uruchom komputer ponownie.
- Obserwuj system przez kilka dni. Zniknięcie błędów 0x154 potwierdza, że awaria leży w ścieżce magazynu skompresowanych stron — nie mówi jeszcze, czy winny jest dysk, RAM czy sterownik.
- Powrót do stanu wyjściowego: Enable-MMAgent -MemoryCompression i restart.
- Traktuj to jako obejście na czas diagnozy, nie jako naprawę. Uszkodzony nośnik po wyłączeniu kompresji zwykle po jakimś czasie zgłosi KERNEL_DATA_INPAGE_ERROR albo zacznie wysypywać aplikacje. Na komputerach z 4-8 GB RAM wyłączenie kompresji zauważalnie zwiększa ruch na pliku stronicowania i spowalnia pracę przy wielu otwartych programach.
Przetestuj pamięć RAM
- Wbudowany test: mdsched.exe, po starcie testu naciśnij F1 i ustaw Test Mix na Extended. Wykrywa tylko grube błędy — czysty wynik niczego nie przesądza.
- Rzetelny test: MemTest86 z pendrive'a, minimum 4 pełne przebiegi (kilka godzin). Jeden zgłoszony błąd wystarczy, żeby uznać pamięć za przyczynę.
- W BIOS wyłącz profil XMP/EXPO i uruchom pamięć na częstotliwości bazowej (2133/2666/4800 MT/s zależnie od platformy). Jeśli BSOD-y ustają, problem jest w profilu podkręcania, a nie w samych kościach.
- Przy dwóch kościach testuj pojedynczo w tym samym slocie, potem zamień slot — to rozdziela wadliwą kość od uszkodzonego slotu lub kontrolera pamięci w procesorze.
Firmware dysku, sterownik kontrolera i Host Memory Buffer
- Ustal model i wersję firmware: Get-CimInstance Win32_DiskDrive | Select Model, FirmwareRevision
- Zaktualizuj firmware narzędziem producenta: WD/SanDisk Dashboard, Samsung Magician, Crucial Storage Executive, Kingston SSD Manager. To nie jest krok teoretyczny — serie WD Black SN770, WD Blue SN580/SN5000 i SanDisk Extreme M.2 dostały poprawki firmware po fali niebieskich ekranów na Windows 11 24H2.
- Jeśli masz dysk NVMe bez własnego DRAM, a awarie zaczęły się po aktualizacji do 24H2, przetestuj ograniczenie Host Memory Buffer: w regedit przejdź do HKLM\SYSTEM\CurrentControlSet\Services\stornvme\Parameters\Device, utwórz wartość DWORD HmbAllocationPolicy i ustaw 0 (HMB wyłączony) albo 2 (limit ok. 64 MB), po czym uruchom komputer ponownie. Kosztuje to część wydajności zapisu — zostaw tylko wtedy, gdy realnie pomogło.
- Sterownik kontrolera: jeśli w Menedżerze urządzeń widnieje Intel RST/VMD, zaktualizuj go ze strony producenta laptopa lub płyty głównej. Jeśli nie korzystasz z RAID, standardowy sterownik Microsoftu (stornvme/storahci) bywa stabilniejszy — ale przełączanie trybu VMD/RAID/AHCI w BIOS bez wcześniejszego przygotowania systemu kończy się błędem INACCESSIBLE_BOOT_DEVICE i komputerem, który nie startuje.
Usuń z drogi sterowniki filtrujące innych producentów
- Wypisz aktywne minifiltry: fltmc filters w wierszu poleceń administratora. Szukaj pozycji spoza Microsoftu — sterowników antywirusów, backupu, szyfrowania dysku.
- Zanim odinstalujesz pakiet zabezpieczeń, sprawdź, czy nie obsługuje szyfrowania dysku (Sophos SafeGuard, ESET Full Disk Encryption, Bitdefender Full Disk Encryption, McAfee Drive Encryption). Usunięcie agenta przy zaszyfrowanym woluminie oznacza utratę dostępu do danych — w takim wypadku najpierw odszyfruj dysk albo skontaktuj się z administratorem.
- Odinstaluj pakiet antywirusowy dedykowanym narzędziem producenta (usuwanie z Aplikacji i funkcji często zostawia sterownik w systemie). Na czas testu wystarczy Microsoft Defender.
- Zatrzymaj agenty backupu i klonowania (Acronis, Veeam Agent, EaseUS ToDo) — services.msc, typ uruchomienia: Wyłączony.
- Czysty rozruch: msconfig → zakładka Usługi → Ukryj wszystkie usługi firmy Microsoft → Wyłącz wszystko, plus wyłączenie autostartu w Menedżerze zadań. Jeśli awarie ustaną, włączaj usługi z powrotem po kilka naraz, aż wróci błąd.
Napraw plik stronicowania i system plików
- Wyłącz Szybkie uruchamianie: powercfg /h off w wierszu poleceń administratora. Dopiero wtedy zamknięcie systemu jest pełnym zamknięciem, a narzędzia naprawcze pracują na spójnym woluminie.
- Skan bez modyfikacji, działa na uruchomionym systemie: chkdsk C: /scan. Naprawa struktur: chkdsk C: /f (wymaga restartu). Zarówno /f, jak i /r uruchamiaj dopiero wtedy, gdy masz kopię danych — oba zapisują na dysk.
- sfc /scannow, a jeśli zgłosi pliki, których nie potrafi naprawić: DISM /Online /Cleanup-Image /RestoreHealth, potem ponownie sfc /scannow.
- Przebuduj plik stronicowania: Właściwości systemu → Zaawansowane → Wydajność/Ustawienia → Zaawansowane → Pamięć wirtualna → Zmień → odznacz automatyczne zarządzanie, ustaw Brak pliku stronicowania, restart, usuń pozostały C:\pagefile.sys, ustaw z powrotem Rozmiar zarządzany przez system, restart.
- Sprawdź wolne miejsce na dysku systemowym. Poniżej kilku GB plik stronicowania nie ma jak się rozszerzyć, a SSD zapełniony powyżej 90% dodatkowo zwalnia i częściej zgłasza opóźnienia.
Sprawdź połączenie, temperaturę i zarządzanie energią dysku
- Wykręć i osadź ponownie dysk M.2, sprawdź dokręcenie śruby i przyleganie padu termicznego do radiatora. Przy dysku SATA wymień kabel danych i spróbuj innego złącza zasilania.
- Sprawdź temperaturę w CrystalDiskInfo lub HWiNFO pod obciążeniem. NVMe powyżej 70-75 °C zaczyna ograniczać wydajność, a przy ok. 80 °C i wyżej potrafi na moment zerwać łącze — to daje dokładnie taki obraz błędu.
- Wyłącz agresywne oszczędzanie energii łącza: Panel sterowania → Opcje zasilania → Zmień zaawansowane ustawienia zasilania → Zarządzanie energią stanu łącza PCI Express → Wyłączone; oraz Dysk twardy → Wyłącz dysk twardy po → 0 (nigdy). W BIOS można dodatkowo wyłączyć ASPM.
- W komputerze stacjonarnym z kilkoma dyskami i mocną kartą graficzną sprawdź zasilacz — spadki napięcia na linii 12 V objawiają się resetami dysku i wpisami 129 w logach.
Przeanalizuj zrzut pamięci, w ostateczności uruchom Driver Verifier
- Upewnij się, że zrzuty się zapisują: Właściwości systemu → Zaawansowane → Uruchamianie i odzyskiwanie → Ustawienia → Zapisywanie informacji o debugowaniu: Mały zrzut pamięci. Pliki trafiają do C:\Windows\Minidump.
- Szybki podgląd bez znajomości debuggera: BlueScreenView albo WhoCrashed — pokażą kod zatrzymania i sterownik na szczycie stosu.
- Analiza właściwa: WinDbg (ze Sklepu Microsoft lub z Windows SDK), polecenie !analyze -v. Przy 0x154 w stosie widać zwykle nt!RtlDecompressBufferXpressLz, nt!ST_STORE<SM_TRAITS>::StDmSinglePageCopy, nt!SMKM_STORE<SM_TRAITS>::SmStDirectRead, nt!MiIssueHardFaultIo, a proces to MemCompression.
- Kod wyjątku kryje się pod parametrem 2 błędu. Microsoft opisuje go tylko jako „informacje o wyjątku", a w praktyce bywa raz wskaźnikiem na EXCEPTION_RECORD, raz na EXCEPTION_POINTERS — spróbuj w WinDbg polecenia .exr <parametr2>, a jeśli zwróci śmieci, obejrzyj strukturę: dt nt!_EXCEPTION_POINTERS <parametr2>. Kod 0xC0000006 wskazuje na nieudane wejście/wyjście (dysk, łącze, sterownik), 0xC0000005 częściej na uszkodzone dane, które już były w pamięci.
- Jeśli w kolejce urządzenia widać zaległe pakiety IRP zatrzymane na sterowniku spoza Microsoftu (klasyczny przykład: iaStorAC.sys od Intel RST), masz konkretnego kandydata na winowajcę.
- Ostatni krok diagnostyczny: Driver Verifier (verifier) ze standardowym zestawem testów, włączony wyłącznie dla sterowników spoza Microsoftu. Wcześniej utwórz punkt przywracania i przygotuj nośnik odzyskiwania — Verifier celowo zatrzymuje system przy pierwszym naruszeniu i potrafi zablokować rozruch (wyłączenie: verifier /reset w trybie awaryjnym). Przy podejrzeniu padającego dysku odłóż ten krok do czasu, aż zrobisz kopię: Verifier zwiększa liczbę twardych zatrzymań.
Wymiana nośnika
- Jeśli SMART pokazuje sektory realokowane lub oczekujące, błędy nieskorygowane albo Available Spare poniżej progu producenta — dysk jest do wymiany, nie do naprawy. Żadne narzędzie programowe nie odbuduje zużytych komórek NAND ani nie cofnie degradacji talerza.
- Klonuj narzędziem, które radzi sobie z błędami odczytu (Macrium Reflect z pomijaniem uszkodzonych sektorów, ddrescue). Pamiętaj, że klon przenosi także uszkodzone pliki — po skopiowaniu uruchom sfc /scannow i DISM /Online /Cleanup-Image /RestoreHealth.
- Bezpieczniejszy wariant: czysta instalacja Windows na nowym dysku i przeniesienie danych z kopii. Zajmuje więcej czasu, ale wyklucza przeniesienie uszkodzonych struktur systemu.
- Po wymianie włącz z powrotem kompresję pamięci (Enable-MMAgent -MemoryCompression) i obserwuj logi przez tydzień. Jeśli 0x154 wróci na nowym dysku, przyczyna leży w pamięci RAM, kontrolerze na płycie albo w sterowniku — i wtedy wracasz do wcześniejszych kroków.
Kiedy to przestaje być kwestią oprogramowania
Jeśli błąd się powtarza, a SMART pokazuje realokowane sektory albo rosnącą liczbę błędów odczytu, dysk jest w trakcie awarii. W tym momencie priorytet się odwraca: ważniejsze od naprawy systemu staje się zgranie danych, zanim nośnik przestanie się zgłaszać. Nie instaluj wtedy systemu ponownie i nie uruchamiaj narzędzi naprawczych — każdy zapis nadpisuje to, co jeszcze da się uratować.
Czym ten błąd różni się od podobnych
Najbliższym krewnym w bazie jest KERNEL_DATA_INPAGE_ERROR (0x7A) i te dwa kody bardzo łatwo pomylić, ale zgłaszają je inne komponenty jądra. 0x7A pochodzi od menedżera pamięci: system próbował wczytać z dysku dowolną stronę (z pliku stronicowania, z pliku wykonywalnego, z pliku odwzorowanego w pamięci), odczyt się nie powiódł, a dokładny kod NTSTATUS trafia wprost do parametrów błędu (np. 0xC000009C, 0xC000016A, 0xC0000185) — Windows wie więc od razu, że problemem było wejście/wyjście. 0x154 zgłasza Store Manager, czyli warstwa obsługująca wyłącznie magazyn skompresowanych stron, a awaria następuje w trakcie rozpakowywania danych algorytmem Xpress, nie samego ich odczytu. Ma to trzy praktyczne konsekwencje. Po pierwsze, 0x154 może wystąpić bez żadnej operacji dyskowej — skompresowane strony leżą w pamięci fizycznej w procesie MemCompression, więc przekłamany bit w RAM psuje strumień i wywala system, podczas gdy 0x7A zawsze oznacza nieudane I/O. Po drugie, w 0x154 nie ma gotowego kodu NTSTATUS w parametrach — trzeba sięgnąć przez parametr 2 do struktury wyjątku, żeby w ogóle stwierdzić, czy zawiódł dysk (0xC0000006), czy dane były już uszkodzone w pamięci (0xC0000005). Po trzecie, ten błąd ma własną dźwignię diagnostyczną, której 0x7A nie ma: Disable-MMAgent -MemoryCompression wyłącza całą ścieżkę i pozwala potwierdzić rozpoznanie w jedną noc. To także powód, dla którego 0x154 jest w tej bazie właścicielem tematu kompresji pamięci. Jeśli trafiłeś tu ze strony MEMORY_MANAGEMENT (0x1A) z podkodem 0x6001, jesteś we właściwym miejscu — 0x6001 oznacza dokładnie uszkodzenie prywatnego zakresu pamięci komponentu magazynu i prowadzi się je tak samo jak 0x154. Od PAGE_FAULT_IN_NONPAGED_AREA (0x50) różnica polega na tym, że tam adres w ogóle nie miał prawa być odwzorowany i nie ma mowy o żadnym odczycie z nośnika. Od NTFS_FILE_SYSTEM (0x24) — na tym, że dostęp do pliku stronicowania idzie skrótem przez warstwę woluminu i nie obciąża logiki NTFS w tym samym stopniu, więc przy 0x154 to nie sterownik systemu plików jest podejrzanym numer jeden.
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
- Potraktuj pierwszy 0x154 jak ostrzeżenie dotyczące dysku i od razu sprawdź SMART — kolejna awaria bywa już taka, po której system nie wstaje.
- Trzymaj kopię danych poza komputerem (dysk zewnętrzny lub chmura) i raz na jakiś czas sprawdź, czy da się z niej faktycznie odtworzyć pliki.
- Raz na kwartał zerknij w CrystalDiskInfo i na wolne miejsce na dysku systemowym — SSD zapełniony powyżej 85-90% pracuje wolniej i szybciej się zużywa.
- Aktualizuj firmware SSD, gdy producent publikuje poprawkę stabilności dla twojego modelu, i rób to zawsze z aktualną kopią danych.
- Nie zostawiaj włączonego XMP/EXPO bez przetestowania konfiguracji MemTest86 po każdej zmianie pamięci.
- W cienkich laptopach dbaj o czystość układu chłodzenia — dysk M.2 leży zwykle tuż obok wentylatora i grzeje się razem z resztą płyty.
- Wyłącz Szybkie uruchamianie (powercfg /h off), jeśli komputer bywa twardo wyłączany, pracuje bez UPS-a albo stoi w konfiguracji dual-boot.
- Instaluj jeden pakiet antywirusowy zamiast dwóch — nakładające się minifiltry to częste źródło błędów w ścieżce dyskowej.
Pytania i odpowiedzi
Nie. Chodzi o memory store, czyli magazyn skompresowanych stron pamięci obsługiwany przez Store Manager w jądrze systemu. Resetowanie Sklepu Microsoft, czyszczenie jego pamięci podręcznej czy wsreset.exe nie mają z tym błędem nic wspólnego i niczego nie zmienią.
Nie zawsze, ale najczęściej to właśnie nośnik lub jego kontroler. W pozostałych przypadkach winna bywa niestabilna pamięć RAM, firmware dysku, sterownik kontrolera albo minifiltr antywirusa. Rozstrzygają trzy rzeczy zrobione w tej kolejności: odczyt SMART, wpisy 51/129/153 w dzienniku systemu i test MemTest86. Bez nich wymiana dysku jest tylko zgadywaniem.
Sam błąd nie kasuje plików — system przerywa pracę, bo nie potrafi odczytać fragmentu pamięci, a nie dlatego, że coś usunął. Ryzyko bierze się z tego, co go wywołało: jeśli dysk zaczyna się sypać, każda godzina dalszej pracy zmniejsza szanse na pełne odczytanie danych. Dlatego kopię robi się przed testami, a nie po nich. Z dysku, który nie startuje, dane zwykle nadal da się odzyskać, ale bywa to droższe niż wcześniejsze zrobienie backupu.
Nie, to obejście. Wyłączenie kompresji usuwa jedynie ścieżkę, w której usterka się ujawniała. Uszkodzony nośnik czy niestabilny RAM zwykle po jakimś czasie zgłosi się inaczej: błędem KERNEL_DATA_INPAGE_ERROR, uszkodzonymi plikami albo wysypującymi się aplikacjami. Traktuj to jako sposób na kilka spokojnych dni potrzebnych do zabezpieczenia danych i dokończenia diagnostyki.
Te narzędzia sprawdzają logiczne struktury systemu plików i integralność plików Windows. Nie badają stanu fizycznego nośnika, jakości łącza ani pamięci RAM. Kolejne kroki to odczyt SMART, przegląd zdarzeń 51/129/153, MemTest86 przez kilka godzin, aktualizacja firmware dysku, a na końcu analiza zrzutu pamięci w WinDbg.
Raczej nie. Problemy z GPU dają zwykle VIDEO_TDR_FAILURE lub zawieszenie obrazu, nie 0x154. Powiązanie z obciążeniem pasuje do dysku i pamięci: przy dużych transferach kontroler NVMe pracuje na granicy i mocniej się grzeje, a przy dużym zużyciu RAM Windows intensywniej kompresuje pamięć, więc magazyn jest odpytywany częściej. Sprawdź temperaturę dysku pod obciążeniem oraz wersję jego firmware.
Wejdź w tryb awaryjny: przytrzymaj Shift i kliknij Uruchom ponownie, dalej Rozwiąż problemy → Opcje zaawansowane → Ustawienia uruchamiania → Uruchom ponownie → klawisz 4. Tryb awaryjny zużywa mniej pamięci, więc kompresja jest wykorzystywana rzadziej i system często wytrzymuje wystarczająco długo, by skopiować dane i sprawdzić SMART. Jeśli i to zawodzi, wypnij dysk i podłącz go do innego komputera.
Odczyt SMART, przegląd dziennika zdarzeń, test pamięci i aktualizacja firmware są do zrobienia w domu — instrukcje powyżej prowadzą przez to krok po kroku. Serwis przydaje się wtedy, gdy komputer nie startuje wystarczająco długo, gdy dane trzeba zdjąć z uszkodzonego nośnika albo gdy testy wychodzą czysto i trzeba zejść do analizy zrzutów pamięci. W naszym serwisie wstępna diagnoza jest bezpłatna — jeśli uda się na tym etapie ustalić przyczynę, podajemy wycenę, a w trudniejszych przypadkach konieczna bywa dodatkowa, płatna diagnostyka.
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ń.