Microsoft подтвердила сбой обновлений Windows на части устройств, которые перешли на Windows 11 24H2 или 25H2 с более ранних версий системы. Проблема неприятна не только для домашних пользователей: если ПК застрял на июньском накопительном пакете, он перестает нормально получать ежемесячные патчи, а для IT-команд это уже не мелкий баг, а брешь в операционной рутине.
О проблеме, как пишет BleepingComputer, компания предупредила 10 июня 2026 года. По данным Microsoft, затронута лишь небольшая доля устройств, но сценарий довольно конкретный: сначала машина работала на Windows 10 21H2 или 22H2 либо на Windows 11 23H2, затем ее обновили до Windows 11 24H2 или 25H2, после чего установка последних cumulative updates начала падать с ошибками 0x80073712 или 0x800f0993. В истории Windows Update такие коды выглядят как знакомый набор букв и цифр, но для администратора это означает вполне приземленную вещь: очередной пакет не встал, следующего тоже может не быть.
Microsoft уточняет, что на затронутых системах в логах Windows Update можно увидеть расшифровки PSFX_E_REBASE_HYDRATION_CANDIDATES_MISSING для 0x800f0993 и ERROR_SXS_COMPONENT_STORE_CORRUPT для 0x80073712. Проще говоря, проблема связана не с тем, что пользователь нажал не туда, а с внутренним состоянием компонентов, которые участвуют в установке накопительных обновлений. И это важный нюанс: когда ломается именно цепочка обслуживания Windows, стандартный совет «попробуйте еще раз позже» превращается в административный фольклор, а не в рабочее решение.
У Microsoft есть хорошая и плохая новости. Хорошая: для неуправляемых корпоративных устройств и домашних ПК компания уже разворачивает исправление, и, по ее словам, после перезагрузки оно должно примениться автоматически. Более того, Microsoft заявила, что новые устройства из этих категорий не должны сталкиваться с проблемой начиная с 19 мая 2026 года, 18:30 по тихоокеанскому времени. Плохая новость в том, что на части уже затронутых машин, которые успели обновиться до 24H2 или 25H2, этот сбой обновлений Windows сам по себе не рассосется: там придется удалять проблемный пакет вручную через DISM. Команда у Microsoft вполне конкретная: dism /online /remove-package /packagename:Package_for_RollupFix~31bf3856ad364e35~amd64~~26100.1742.1.10. Если и это не помогает, компания советует делать in-place upgrade Windows 11.
Отдельно Microsoft перечислила обновления, которые должны автоматически ставиться во время апгрейда и не допускать этой поломки в будущем. Для Windows 10 21H2 и 22H2 исходным проблемным пакетом назван KB5082200, а исправлением — KB5094127. Для Windows 11 23H2 это связка KB5082052 и KB5093998. Для Windows 11 24H2 и 25H2 фигурируют KB5079391 и KB5094126. На бумаге все выглядит аккуратно: есть происхождение бага, есть нужный пакет, есть remediation path. На практике же это еще один пример того, как миграция между версиями Windows легко превращается в квест с проверкой журналов, ручным удалением пакетов и осторожным выбором окна для следующей перезагрузки.
Контекст у этой истории показательный. За последние месяцы Microsoft уже несколько раз исправляла сбои в механике обновлений. В апреле компания выпускала внеплановое обновление из-за проблем с мартовским необязательным preview-пакетом KB5079391, который тоже мог вызывать ошибку 0x80073712 при развертывании Windows 11. В мае Microsoft предупреждала о сбоях Windows Update после установки январских необязательных preview-обновлений в сетях с ограничениями. Совсем недавно компания также закрыла известную проблему с ошибкой 0x800f0922 при установке майского security update KB5089549 для Windows 11. Если собрать эти эпизоды в одну линию, получается не единичный инцидент, а затянувшаяся серия шероховатостей в том месте, где от платформенного вендора обычно ждут скучной предсказуемости.
Для российских IT-команд здесь несколько практических выводов. Во-первых, парк устройств после перехода на Windows 11 24H2 и 25H2 стоит проверить не по принципу «жалоб нет, значит все хорошо», а по факту прохождения июньских cumulative updates. Во-вторых, важно разделять управляемые и неуправляемые устройства: Microsoft прямо говорит, что часть исправления прилетит автоматически именно на unmanaged enterprise devices и домашние редакции. В-третьих, если в компании есть собственные инструкции по апгрейду рабочих станций, туда уже сейчас имеет смысл добавить проверку ошибок 0x80073712 и 0x800f0993, а также процедуру с удалением пакета через DISM. Иначе сбой обновлений Windows всплывет не в момент планового обслуживания, а когда очередной уязвимый хост внезапно окажется без актуальных патчей.
Для разработчиков и продактов эта новость тоже не чужая. Когда у команды часть рабочих машин не получает ежемесячные обновления, это быстро выходит за пределы администрирования: ломаются сроки тестирования, откладываются roll-out’ы, растет разброс по версиям ОС, сложнее воспроизводить баги и валидировать совместимость корпоративного софта. А для IT-директора это еще один аргумент в пользу более дисциплинированного контроля жизненного цикла устройств: сам переход на новую версию Windows давно уже не финальная галочка, а только начало цепочки, где каждое накопительное обновление может добавить сюрприз.
История неприятна не масштабом, а симптомом. Windows все активнее живет в режиме непрерывного апдейта, но чем плотнее становятся зависимости между версиями, пакетами и путями миграции, тем дороже обходится даже небольшой сбой в механизме обслуживания. Для бизнеса это означает простую вещь: надежность обновлений снова становится инфраструктурной метрикой, а не фоном, который замечают только в день Patch Tuesday.