Обновление Windows 11 KB5063878: как патч безопасности превратился в угрозу для накопителей

Август 2025 года должен был стать очередной вехой в защите пользователей Windows 11 от киберугроз. Microsoft традиционно выпустила кумулятивное обновление KB5063878 для версии 24H2, обещая устранение уязвимостей и повышение стабильности системы. Однако реальность оказалась куда более драматичной: вместо повышения безопасности многие владельцы компьютеров столкнулись с исчезновением данных, превращением накопителей в нечитаемые RAW-разделы и зависаниями на печально известном "синем экране смерти". Что именно пошло не так с этим обновлением и почему проблема дошла до российских пользователей лишь к декабрю?

Что скрывается за номером KB5063878

12 августа 2025 года компания Microsoft представила KB5063878 как часть ежемесячного цикла обновлений Patch Tuesday. Официально патч предназначался для решения проблем с задержками входа в систему на новых устройствах, вызванными предустановленными приложениями, а также включал исправления для критических уязвимостей безопасности, включая CVE-2025-50173. Никто не предполагал, что в недрах этого, казалось бы, рутинного апдейта скрывается механизм, способный буквально парализовать работу SSD и HDD накопителей.

Первые тревожные сигналы появились практически сразу после релиза. Пользователи из Японии и Европы начали сообщать о странных сбоях: при записи больших объемов данных, обычно превышающих 50 гигабайт, твердотельные накопители внезапно исчезали из системы. Поначалу эти инциденты воспринимались как единичные случаи, возможно, связанные с аппаратными дефектами конкретных устройств. Однако по мере распространения обновления стало очевидно: проблема носит системный характер.

Механизм сбоя оказался коварным в своей избирательности. Обновление не "убивало" накопители моментально и не у всех подряд. Существовала четкая закономерность: диски, заполненные более чем на 60%, при длительной непрерывной записи больших файлов становились особенно уязвимы. В этот момент контроллер SSD переставал отвечать на запросы системы, накопитель исчезал из проводника Windows, а SMART-данные становились недоступными. После перезагрузки раздел мог превратиться в RAW, означающий потерю файловой системы NTFS, или диск вовсе не определялся ни в операционной системе, ни в BIOS.

Техническая анатомия проблемы

Чтобы понять суть проблемы, стоит разобраться в том, как обновление повлияло на работу подсистемы хранения данных Windows 11. По версии технических специалистов, KB5063878 внес изменения в механизмы кеширования и буферизации операций ввода-вывода. Когда система работает с почти заполненным накопителем и выполняет интенсивную последовательную запись данных, контроллер SSD должен одновременно управлять несколькими процессами: записью новых данных, сборкой мусора для освобождения места и выравниванием износа ячеек памяти NAND.

Обновление, судя по всему, изменило стратегию управления очередью операций записи. Windows перестала корректно синхронизировать буферы с контроллером, что при высокой нагрузке приводило к переполнению внутренних буферов SSD. Контроллер, не успевая обработать поток данных, входил в состояние зависания. Особенно уязвимыми оказались накопители без выделенного DRAM-буфера, которые используют технологию HMB (Host Memory Buffer), то есть заимствуют память у системы. В такой конфигурации любые сбои в управлении кешем со стороны операционной системы мгновенно сказываются на стабильности работы диска.

Контроллеры Phison серий E16, E18 и E31T, широко используемые в популярных моделях SSD от Corsair, Western Digital, SanDisk и Kioxia, оказались в зоне особого риска. Однако проблема затронула и другие контроллеры, включая решения от InnoGrit и Maxio. Даже некоторые модели от Samsung с фирменными контроллерами не избежали сбоев, хотя и в меньшей степени. Это указывает на то, что корень проблемы кроется именно в поведении операционной системы, а не в дефектах конкретных компонентов.

География распространения: от Японии до России

Интересен временной аспект распространения проблемы. Если первые массовые жалобы из Японии и стран Европы появились уже в середине августа 2025 года, то в России настоящая волна недовольства накрыла пользователей лишь в конце ноября и начале декабря. 6 декабря российские СМИ и Telegram-каналы, зафиксировали резкий всплеск сообщений о "синих экранах смерти" и потере доступа к накопителям.

Эта задержка объясняется несколькими факторами. Во-первых, распространение обновлений Windows происходит поэтапно, с учетом региональных особенностей и нагрузки на серверы обновлений. Во-вторых, многие российские пользователи и организации традиционно откладывают установку апдейтов, предпочитая дождаться отзывов и убедиться в отсутствии критических ошибок. Корпоративный сектор часто использует политики отложенных обновлений, что также замедляет распространение патчей. К тому же, особенности работы серверов обновлений в разных регионах и приоритеты распространения играют свою роль в том, когда именно патч достигает конкретной группы пользователей.

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

Позиция Microsoft и производителей

Реакция Microsoft на возникшую ситуацию оказалась неоднозначной. С одной стороны, компания официально заявила о проведении расследования, что подтверждает серьезность инцидента. С другой стороны, после нескольких недель тестирования представители корпорации объявили, что "не обнаружили связи между августовским обновлением безопасности и сообщениями о сбоях твердотельных накопителей, появившихся в социальных сетях".

Microsoft подчеркнула, что внутреннее тестирование не выявило повышенного риска отказа дисков, а телеметрические данные от миллионов устройств не показали статистически значимого всплеска подобных проблем. Более того, в официальных комментариях утверждалось, что ни один клиент не обращался напрямую в службу поддержки с такими жалобами, хотя форумы Microsoft Q&A и Reddit были наводнены детальными описаниями проблемы.

Производитель контроллеров Phison провел собственное масштабное исследование. Инженеры компании потратили более 4500 часов на тестирование накопителей, предположительно затронутых проблемой, выполнив свыше 2200 тестовых циклов. Результат оказался таким же: воспроизвести заявленную ошибку не удалось. Представители Phison высказали версию, что корень проблемы может крыться в предрелизных версиях прошивок некоторых накопителей или в специфических условиях эксплуатации, которые сложно воссоздать в лабораторных условиях.

Тем не менее факты упрямы. Сотни пользователей по всему миру, включая российских владельцев компьютеров, сообщают об идентичных симптомах, возникающих исключительно после установки KB5063878. Многим помогал откат обновления, что косвенно указывает на связь между патчем и проблемой. Возникла ситуация, когда официальные заявления производителей расходятся с массовым опытом пользователей.

Практические рекомендации и способы защиты

Для тех, кто уже столкнулся с проблемой или опасается ее появления, существует ряд практических шагов. Наиболее эффективным решением оказывается удаление проблемного обновления. Это можно сделать через настройки Windows: перейти в "Параметры", затем "Центр обновления Windows", выбрать "Журнал обновлений" и в разделе удаления найти KB5063878. После удаления рекомендуется приостановить автоматическую установку обновлений на несколько недель, чтобы избежать повторной установки патча.

Важный нюанс: некоторые пользователи сообщают, что удаление обновления блокируется системой с ошибкой 0x800F0825. В таких случаях помогает временное отключение компонента Windows Sandbox (Песочница Windows) через панель управления компонентами, после чего удаление проходит успешно.

Если накопитель уже превратился в RAW-раздел, ни в коем случае не следует соглашаться на форматирование. В большинстве случаев физически данные остаются нетронутыми, повреждается лишь таблица разделов и файловая система. Специализированные утилиты восстановления данных, такие как TestDisk, DMDE или R-Studio, способны восстановить структуру раздела и вернуть доступ к файлам. Рекомендуется загрузиться с Live USB-системы на базе Linux, чтобы минимизировать риск дополнительных записей на поврежденный диск.

Для профилактики стоит соблюдать несколько правил. Не стоит заполнять SSD более чем на 70-75% емкости, это не только снижает риск подобных сбоев, но и продлевает срок службы накопителя. При необходимости записи больших объемов данных лучше делать это порциями, избегая непрерывных сессий записи более 40-50 гигабайт. Регулярное создание резервных копий критически важных данных на внешние носители или в облачные хранилища остается золотым правилом, которое способно спасти от потери информации при любых сбоях, не только связанных с обновлениями системы.

Более широкий контекст и уроки инцидента

История с KB5063878 высветила фундаментальную проблему современных операционных систем: баланс между безопасностью, стабильностью и необходимостью быстрого реагирования на угрозы. Microsoft находится под постоянным давлением, вынуждена оперативно закрывать уязвимости, используемые злоумышленниками. Однако такая спешка иногда приводит к тому, что обновления не проходят достаточно всесторонне тестирование на разнообразных конфигурациях оборудования.

Современные компьютеры используют десятки тысяч различных комбинаций процессоров, материнских плат, накопителей и периферийных устройств. Протестировать обновление на всех возможных сочетаниях физически невозможно. Именно поэтому некоторые ошибки проявляются только в реальных условиях эксплуатации, когда миллионы пользователей устанавливают патч на свои уникальные системы.

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