Ошибка 0x154 при запуске игр: код ругается на память, а виноват накопитель

Содержание

Синий экран с кодом 0x154 (UNEXPECTED_STORE_EXCEPTION) означает, что ядро Windows не смогло прочитать страницу памяти из сжатого хранилища. Код назван по компоненту памяти, поэтому первым делом обычно проверяют оперативку. Но в минидампе виновник виден прямо в стеке — и им часто оказывается накопитель, который не отдал страницу под нагрузкой.

Ниже — разбор реального дампа с компьютера, где тяжёлая игра стабильно валила систему. Показываю, какие строки отчёта !analyze -v указывают на накопитель, и что проверить по порядку.

Сразу главное: 0x154 — это следствие, а не причина. Лечить сам код бессмысленно: искать нужно первопричину в стеке и в железе.

Что означает код 0x154 #

Когда оперативной памяти не хватает, Windows не сразу сбрасывает данные на диск. Сначала она пытается их сжать и держит в особом хранилище — store. За это отвечает процесс MemCompression. Если сжатую страницу всё-таки нужно выгрузить, она уходит в файл подкачки, а при обращении возвращается обратно и распаковывается.

Код 0x154 означает, что при работе с этим хранилищем произошло непредвиденное исключение: ядро ожидало данные, а получить их не смогло. Официальная формулировка Microsoft — «компонент хранилища памяти ядра перехватил непредвиденное исключение». Про виновника она молчит: имя кода описывает место сбоя, а не его причину.

Почему код про память, а падает из-за диска #

Смотрите дальше по цепочке. Чтобы поднять сжатую страницу обратно в память, Windows должна прочитать её с диска. Если чтение не удалось, распаковка данных тоже не удаётся, и система останавливается. Storage-компонент в этом сценарии — тот, кто сообщает о сбое, а не тот, кто его вызвал.

Получается так: памяти не хватает → включается сжатие и подкачка → при обращении к странице идёт чтение с диска → диск не отдаёт её → ядро падает с 0x154. Память здесь работает как нагрузка, а не как поломка; ломается чтение.

Как открыть и прочитать свой минидамп #

Минидампы лежат в C:\Windows\Minidump. Имя файла вида 100426-25984-01.dmp — это один конкретный крах: дата и порядковый номер.

Дальше нужен отладчик. В Microsoft Store он называется WinDbg, открывается бесплатно. Открываем в нём дамп и выполняем команду:

!analyze -v

Отладчик сам подтянет символы и соберёт разбор. Без этой команды дамп — просто набор байтов. Первый запуск может занять несколько минут: WinDbg скачивает пакет символов из сети.

Разбор дампа: где виден виновник #

Вот ключевые строки из отчёта !analyze -v на дампе, где система стабильно падала в игре:

BUGCHECK_CODE:  154   UNEXPECTED_STORE_EXCEPTION
PROCESS_NAME:   MemCompression
ExceptionCode:  c0000006  (In-page I/O error)
Inpage operation failed at ... , due to I/O error 00000000c000000e
IMAGE_NAME:     storahci.sys
FAILURE_BUCKET_ID: 0x154_c0000006_c000000e_IMAGE_storahci.sys

Перевод на человеческий. Процесс MemCompression пытался поднять сжатую страницу памяти, для чего её нужно было прочитать с диска. Чтение упало с ошибкой c000000e — это STATUS_NO_SUCH_DEVICE, «устройство не найдено». Дальше ядро не смогло распаковать страницу и остановилось.

Две детали здесь важнее всего:

IMAGE_NAME: storahci.sys — это штатный драйвер AHCI-контроллера Windows. Именно на него указывает отчёт, а не на драйвер памяти.
c000000e, STATUS_NO_SUCH_DEVICE — «устройства нет». Не «ошибка данных», не «нет памяти», а накопитель, который перестал отвечать на чтение.

Стек вызовов это подтверждает. Внизу — рабочий поток, который в этот момент сканировал шину накопителя: storport!RaidAdapterRescanBus, storport!RaDriverPnpIrp, nt!PnpDeviceActionWorker. А сама ошибка чтения возникла в nt!RtlDecompressBufferLz4 — там, где ядро распаковывало страницу. То есть система пересматривала контроллер диска, попутно потребовалась страница из сжатого хранилища, диск её не отдал — и ядро упало.

В том же дампе видно и само железо: контроллер, диск и его модель. Это оказался Seagate Barracuda на 500 ГБ, 7200 об/мин — обычный жёсткий диск, выпущенный больше десяти лет назад.

Почему именно в тяжёлых играх #

Здесь всё сходится. Тяжёлая игра съедает несколько гигабайт памяти и постоянно читает файлы с диска. Памяти не хватает — включается сжатие и подкачка, а нагрузка на накопитель вырастает в разы. Старый HDD к таким рывкам уже не готов.

Пока задача лёгкая, ошибки чтения проскакивают незаметно: редкие обращения не попадают в сбойный участок. Как только начинается настоящая нагрузка, система натыкается на проблему и падает. Поэтому симптом и выглядит странно: в нетребовательных играх всё стабильно, а в новой — синий экран.

Что проверить по порядку #

Порядок такой: сначала подтверждаем проблему с накопителем, потом лечим. Память — не первый шаг.

1. Здоровье накопителя. Поставьте CrystalDiskInfo и посмотрите SMART. Красные флаги — «Переназначенные сектора» (атрибут 05), «Нестабильные сектора» (C5) и «Ошибки CRC» (C7). Затем проверка поверхности:

chkdsk D: /f /r

Букву диска подставьте свою. Ключ /r ищет битые секторы, /f исправляет ошибки файловой системы. На большом диске это может занять часы — и на подозрительном накопителе перед этим лучше сделать резервную копию.

2. Журнал событий. Откройте eventvwr.msc → «Журналы Windows» → «Система». Ищите записи источника disk с кодами 7, 11, 51, 153 и источника storahci с кодом 129. Событие 129 — «сброс устройства»: контроллер потерял накопитель и перезапустил его. По документации Microsoft событие 129 связано с перегрузкой подсистемы хранения, а на практике это частая реакция на плохой кабель. Если такие сбросы идут пачками под игровой нагрузкой, замена кабеля и перестановка в другой SATA-порт должны стать первой проверкой.

3. Кабель и порт. Самое дешёвое и частый ответ. Замените SATA-кабель, переставьте диск в другой порт, проверьте питание. Ошибка «устройство не найдено» часто означает именно отвал из-за контакта: нет контакта — нет диска.

4. Драйверы и BIOS. Обновите драйверы чипсета и контроллера SATA/AHCI с сайта производителя материнской платы. Проверьте режим AHCI в BIOS и его версию. В разобранном дампе фигурировали storahci и storport — это стандартный AHCI-стек Windows, и обычно он не требует замены.

5. Подкачка и игры — на SSD. Если система стоит на SSD, а игры или файл подкачки лежат на старом HDD, перенесите их. Подкачку меняют так: sysdm.cpl → «Дополнительно» → «Быстродействие» → «Дополнительно» → «Виртуальная память».

6. Память — вторым шагом. Код 0x154 иногда даёт и сбойная оперативка. Прогоните «Диагностику памяти Windows» или MemTest86 — но после проверки диска. В разобранном дампе улики указывали именно на накопитель.

Ограничения: одного дампа мало #

Один дамп — это один крах, а не диагноз. Чтобы вывод был уверенным, соберите два-три минидампа и сравните: если FAILURE_BUCKET_ID каждый раз содержит IMAGE_storahci.sys, а в стеке мелькает тот же диск — вопрос закрыт. Если код ошибки и стек меняются от раза к разу, причина может быть в памяти или в драйвере.

Отдельно стоит помнить: код 0x154 и 0x7A (KERNEL_DATA_INPAGE_ERROR) относятся к одному семейству — «не удалось прочитать страницу с диска». Разные коды, одна природа.

И главное: 0x154 — это следствие. Бессмысленно «лечить» сам код. Ищите первопричину в стеке и в железе, а не меняйте память и видеокарту наугад.

Частые вопросы #

Можно ли поставить диагноз по одному дампу? Нет. Один дамп показывает один крах и одного кандидата-виновника. Уверенный вывод делают по двум-трём дампам: важен повторяющийся FAILURE_BUCKET_ID и один и тот же диск в стеке.

0x154 и 0x7A — это одно и то же? Не одно и то же, но родственное. Оба означают, что Windows не смогла прочитать нужную страницу с накопителя. Причина при этом может быть общей — диск, кабель или контроллер.

Всегда ли виноват жёсткий диск? Нет. 0x154 иногда даёт сбойная оперативка или проблемный драйвер. Но если в стеке стоит storahci, а ошибка чтения — STATUS_NO_SUCH_DEVICE, проверять нужно накопитель и его подключение в первую очередь.

Чем читать дамп, кроме WinDbg? Полноценный разбор стека делают отладочные инструменты вроде WinDbg. Онлайн-сервисы существуют, но они просят загрузить дамп целиком, а это файл вашей системы — безопаснее разбирать локально.

Если ошибка повторяется, а chkdsk и замена кабеля не помогли, накопитель стоит проверить на другом компьютере и держать под рукой свежую резервную копию. Диагностику смежных сбоев диска разбирали в материале про пропавший диск, который Windows предлагает отформатировать, а логику чтения чужих ошибок по номеру — на примере кода 0x80073712.

Разбирать дампы и ошибки Windows — то, чем я занимаюсь постоянно. Если не хочется читать стек самому, пришлите свой минидамп или код ошибки: посмотрю, что в нём видно, и подскажу, что проверять дальше. Пишите в чат на сайте — отвечу.