В какой-то момент в жизни моей настольной системы ПК я получил два синих экрана подряд во время игры в видеоигры. После этого мне удалось остановить сбой системы, переподключив все оборудование, но по какой-то причине все обновления Windows, которые влияли на систему, такие как ежегодное обновление с 1803 до 1903 и случайное обновление .NET Framework до 4.8 для версии Windows 1803, продолжали не устанавливаться. Поскольку они не были обязательными, я не обращал на них внимания, поскольку регулярные обновления безопасности для Windows Defender все еще работали. В какой-то момент я запустил средство устранения неполадок Центра обновления Windows, которое сообщило, что они обнаружили некоторые ошибки, но перезагрузка запустит процедуру исправления.
В какой-то момент я решил снова заставить обновления работать. Ошибки обновления были 0x8000ffff для обновления .NET и 0x800700C12 для обновления Windows.
При поиске в Интернете вы найдете кучу всякой ерунды, поскольку мы все знаем, что любые ошибки Windows — это идеальное место, где уязвимые пользователи могут установить вредоносное ПО.
Загрузка MediaCreationTool и указание ему выполнить ручное обновление до 1903 также не удалась с "критической ошибкой", хотя, казалось, ничто не повлияло на систему, и он просто не применил никаких изменений. Хотя никаких журналов нет (СПАСИБО MICROSOFT ЗА ЭТИ ПОЛЕЗНЫЕ СООБЩЕНИЯ ОБ ОШИБКАХ)
Сброс журнала обновлений Windows с помощью команды PowerShell GetWindowsUpdateLog дал мне возможность узнать... немного. Чтение этих журналов ошибок утомительно и сложно, а различие между ошибками и сбоями, а также тот факт, что есть вовлеченные системы, о которых вы никогда не услышите при нормальной работе (по крайней мере, в Linux вы знаете, какие системы используете и устанавливаете при настройке системы), не помогли.
Затем я попытался вручную установить .NET 4.8 Framework. Он также не смог выполнить обычную установку, но, по крайней мере, он выгрузил доступный для поиска .xml в какое-то случайное место на моих дисках (он по какой-то причине выгрузил файлы установки на мой медленный жесткий диск объемом 2 ТБ, а не куда-то на SSD, на котором была установлена система, например. Но эй! Windows и временные файлы! Что может пойти не так, если временные файлы никогда не очищаются?). Так что, разбираясь с этим, я обратил внимание, что некоторая программа командной строки, запущенная на последних этапах установки, дала сбой и вернулась с тем же кодом ошибки 0x8000ffff: wusa.exe
Сравнивая сообщения об ошибках, можно выделить хотя бы одну распространенную ошибку во время установки: часть финализации завершается неудачно.
В поисках способов исправления проблемы с обновлением Windows я нашел совет попробовать использовать:
sfc /scannow
и
dism.exe /online /cleanup-image /restorehealth
sfc выдал ошибку с информацией о том, что все еще ожидаются изменения в системе и что мне следует перезагрузить ПК. Я делал это в течение последних 6 месяцев каждый день, так что это не могло быть решением.
dism.exe рухнул на отметке 82,6% и, по крайней мере, дал мне подсказку, что есть логи, которые можно найти и изучить. Хотя они также не были очень полезны в своем формате, он также рухнул на каком-то этапе финализации.
В поисках способа заставить sfc снова работать я нашел случайный пост на форуме, в котором пользователю предлагалось удалить pending.xml в каталоге WinSxS. Заглянув в этот каталог (для чего бы он ни использовался), я нашел pending.xml — он был размером почти 300 МБ. Что-то не так.
Удаление файла от имени администратора не работает. Я продолжаю получать ошибки об отказе в доступе. Даже загрузка PSTools и открытие оболочки Power Shell от имени пользователя SYSTEM лишает меня прав на его удаление. Нет процессов, хранящих дескриптор файла.
Как исправить этот беспорядок и как связаны между собой все эти ошибки?
решение1
Оказалось, что все это представляет собой запутанный клубок ошибок.
Синий экран (первый за 10 лет), который я получил во время игры в видеоигры, похоже, случился, когда обновление Windows что-то устанавливало в фоновом режиме. Было ли виновато само обновление, я не знаю, но мне пришлось приложить некоторые усилия, чтобы снова запустить систему, поскольку оно сообщило, что загрузочный скрипт поврежден. Тогда, я полагаю, я запустил какой-то базовый инструмент командной строки из расширенного меню устранения неполадок при загрузке, чтобы исправить проблему с загрузкой. Затем я переподключил все, потому что журналы ошибок сообщили мне, что что-то странное произошло во время записи данных на диск, поэтому я подумал, что по какой-то причине проводное соединение с системным SSD было разорвано во время работы системы. После того, как это было исправлено, система снова заработала гладко, но обновления больше не работали.
Оказывается, "повреждение файла" зашло глубже. Похоже, что внутри pending.xml находится список обновлений, которые должны быть применены при перезагрузке ПК. Однако этот .xml-файл был каким-то образом поврежден, не позволяя Windows успешно ПРОЧИТАТЬ его содержимое, но все же позволяя ей ДОБАВЛЯТЬ в поврежденный файл все обновления, которые, по ее мнению, она должна была применить, таким образом считывая произвольный объем данных из файла, а затем добавляя все эти данные в конец при каждой перезагрузке, раздувая его все больше и больше, и достигая почти ГБ пропорций метаданных об ожидающих обновлениях.
Поскольку обновление Windows и установщик .NET также хотят сообщить системе «Что-то нужно сделать при следующем перезапуске устройства» на этапе завершения, даже автономные установщики и ручное обновление с помощью инструмента создания носителя также не смогли правильно проанализировать и добавить в pending.xml. Поскольку все это было сломано, ComponentBasedServicing, похоже, отвечал за некоторые программы, поэтому это был CBS, который появлялся то тут, то там в файлах журнала ошибок.
Теперь к решению:
Сначала мне пришлось загрузиться в режиме устранения неполадок с USB-накопителя, который я настроил с помощью инструмента создания носителя.
Там я запустил командную строку и вручную удалил файл pending.xml в каталоге WinSxS.
После этого мне удалось запустить и, sfc /scannowнаконец, получить отчет о том, что некоторые файлы были повреждены, а некоторые были исправлены, но не все.
После этого мне удалось запустить программу, dism /online /cleanup-image /restorehealthкоторая не удалась, так как не удалось найти источник для очистки.
После этого я смог запустить dism /online /cleanup-image /startcomponentcleanupочистку службы компонента
После этого мне удалось провести еще один /restorehalthуспешный забег.
После этого мне удалось сбросить кэш Центра обновления Windows и повторно загрузить все ожидающие обновления и улучшения.
После этого мне удалось установить обновление 1903, а также обновление .NET Framework.
Теперь все КАЖЕТСЯ хорошо.
Мне бы хотелось, чтобы Windows предоставляла пользователю (а не только суперпользователю) более четкую информацию о том, что сломалось или не сломалось в системе, когда ЧТО-ЛИБО ломается.
Этот поиск был адом. И я выбрался из него.