Что случилось и почему это важно
Мы уже упоминали баг File History в числе прочих проблем сентябрьского Patch Tuesday, но по мере появления подробностей выяснилось: это куда серьёзнее, чем казалось изначально. По данным независимого тестирования Windows Latest, после обязательного обновления KB5124008 (8 сентября) File History перестаёт нормально создавать резервные копии практически у всех, кто это обновление установил, при этом большинство пользователей даже не замечают, что их бэкапы молча остановились.
Самое неприятное здесь именно слово «молча»: File History не выдаёт явной ошибки, а вместо этого показывает ложные предупреждения, из-за которых кажется, что проблема на стороне пользователя, а не Windows.
Официальные симптомы от Microsoft
22 сентября, спустя две недели после того, как баг сломал резервное копирование у всех, Microsoft наконец опубликовала официальное заявление: после установки KB5124008 часть пользователей File History не может создавать или обновлять резервные копии.
Конкретные симптомы, которые подтверждает сама Microsoft и независимое тестирование:
- Ложное предупреждение «Переподключите диск», хотя внешний или сетевой диск физически подключён, исправен и прекрасно виден в Проводнике и других программах.
- Неверная метка времени последнего бэкапа, показывается устаревшая или заведомо неправильная дата, из-за чего пропадает весь смысл функции, невозможно понять, какая версия файла реально сохранена.
- В Просмотре событий (Event Viewer) в части случаев фиксируются сбои приложения, ссылающиеся на
FileHistory.exeиKERNELBASE.dll.
Как проверить, затронуты ли вы
- Откройте
Панель управления→Система и безопасность→ «История файлов». Официальное описание работы функции есть в документации Microsoft: Backup and restore with File History. - Обратите внимание на время последнего резервного копирования, если оно явно устарело (не обновлялось несколько дней, хотя диск был подключён), это тревожный признак.
- Проверьте Просмотр событий Windows (
eventvwr.msc) на предмет ошибок, связанных сFileHistory.exe.
Если ваш диск действительно отключён или недоступен, предупреждение о переподключении будет верным. Проблема именно в том, что оно появляется даже когда с диском всё в порядке.
Полная хронология: что чинили и что осталось сломанным
| Дата | Обновление | Сборка 25H2 | Сборка 24H2 | Что произошло |
|---|---|---|---|---|
| 8 сентября | KB5124008 (плановый Patch Tuesday) | 26200.9445 | 26100.9445 | Обязательное обновление, после которого начались проблемы с File History и рядом других функций |
| 14 сентября | KB5129195 (экстренное обновление) | 26200.9457 | 26100.9457 | Исправлены RDP, общие папки Hyper-V/Plan9 и многоканальный звук. File History всё ещё не работает |
| 22 сентября | KB5124010 (необязательное превью) | 26200.9550 | 26100.9550 | Microsoft официально признала баг File History и включила фикс именно в это обновление |
Ключевой нюанс: фикс File History есть только в необязательном превью-обновлении KB5124010, а не в обязательном накопительном патче. Если вы не устанавливаете превью-обновления вручную, придётся ждать, пока фикс попадёт в плановый октябрьский Patch Tuesday, запланированный на 13 октября.
Что делать прямо сейчас
Если вам не критично ждать: установите KB5124010 через «Необязательные обновления» в Центре обновления Windows, это устраняет проблему уже сейчас, но учтите, что превью-обновления в целом менее протестированы и иногда приносят собственные баги, мы уже писали о проблеме с вылетами игр именно в этом обновлении.
Если вы предпочитаете не рисковать с превью-сборкой: используйте OneDrive для резервного копирования нужных папок как временную замену File History до 13 октября.
Для критичных данных в любом случае: не полагайтесь только на File History в ближайший месяц, если у вас есть возможность, продублируйте важные файлы вручную на внешний носитель или в облако, пока функция официально не восстановлена в стабильном канале.
Что с Windows 10
Для Windows 10 отдельного исправления, судя по всему, не будет вообще, в отличие от Windows 11 путь через превью-обновление здесь недоступен. Практические варианты те же, что мы указывали ранее: удалить сентябрьские обновления, если File History критичен, либо переждать с альтернативным способом бэкапа до следующего цикла патчей.
Другие проблемы того же обновления, для контекста
File History не единственная жертва KB5124008. Напомним список, если вы ещё не читали наши предыдущие материалы: RDP и Hyper-V/Plan9 (уже исправлены), USB-звук и AMD GPU (частично исправлены, фикс не раньше октября), доверие домена (есть временный обходной путь), и теперь ещё Always On VPN.
Что ещё нужно знать
Почему Microsoft признала баг только 22 сентября, а не сразу 8 сентября?
Официального объяснения задержки нет. По наблюдениям изданий, отслеживающих проблему, это довольно типичная картина для сентябрьского цикла обновлений в целом, признание проблем занимало от нескольких дней до пары недель почти по каждому пункту.
Пропали ли уже созданные резервные копии из-за этого бага?
Нет, ранее сохранённые копии на внешнем или сетевом диске остаются нетронутыми и доступными для восстановления. Проблема именно в создании новых бэкапов, а не в удалении старых.
Стоит ли полностью переходить на OneDrive вместо File History?
Это вопрос личных предпочтений и объёма данных, OneDrive хорошо подходит как временная мера, но у него другие лимиты (объём бесплатного хранилища, синхронизация вместо версионирования файлов), так что для постоянной замены стоит сначала оценить, подходит ли он под ваш сценарий использования.
Если у меня уже установлен KB5124010, нужно ли что-то донастраивать?
Нет, если фикс вошёл в состав этого обновления, как заявляет Microsoft, File History должен заработать штатно после установки и перезагрузки, дополнительных действий не требуется.
В сухом остатке
File History оказался куда более пострадавшей функцией сентябрьского Patch Tuesday, чем казалось по первым сообщениям: проблема массовая, а не единичная, и, что хуже, полностью незаметна без ручной проверки. Если вы используете File History и ещё не проверяли дату последнего бэкапа, сделайте это сейчас, а не после того, как понадобится восстановить файл, которого на самом деле не оказалось в резервной копии.
