0x80242017 ошибка агента обновлений windows 80242017

Обновлено: 03.07.2024

Пользователи Windows 10 Fast Ring иногда могут столкнуться с ошибкой при обновлении версии Windows 10 Technical Preview до следующей сборки. Очевидно, ошибка 0x080246017 часто обнаруживается, и установка обновления застревает. К счастью, есть решение этой проблемы, и вы найдете его в этой статье.

Вы можете попробовать одно из этих трех решений, чтобы устранить ошибку обновления 0x080246017 в Windows 10.

Решение 1. Удалите предыдущие установочные файлы Windows

Наиболее распространенным решением для ошибки 0x08246017 является удаление предыдущих установочных файлов Windows. Чтобы удалить эти файлы, просто сделайте следующее:

  1. Введите следующую команду и нажмите Enter:
    • rundll32.exe pnpclean.dll, RunDLL_PnpClean/DRIVERS/MAXCLEAN
  2. Закройте командную строку
  3. Теперь перейдите к поиску, введите очистки диска и один инструмент очистки диска
  4. Удалить временные файлы и предыдущие установки Windows
  5. Перезагрузите компьютер

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

  • СВЯЗАННЫЕ: ИСПРАВЛЕНИЕ: регистрация службы обновления Windows отсутствует или повреждена

Решение 2. Сброс значений ключей реестра

Установка новой сборки должна вернуть значения ключей реестра в нормальное состояние, но если это не удастся, вы не сможете установить обновление. Чтобы устранить эту проблему, просто следуйте этим инструкциям:

  1. Перейти к поиску, введите regedit и откройте редактор реестра
  2. Перейдите по следующему пути:
    • HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsSelfHostApplicability
  3. Найдите BranchName и проверьте, показывает ли он FBL_AWESOME1501 (если нет, измените его)
  4. Найдите TresholdRiskLevel и измените его на низкий
  5. Найдите TresholdInternal и удалите его
  6. Найдите TresholdOptedIn и удалите его
  7. Закрыть редактор реестра

Решение 3. Запустите средство устранения неполадок обновления


Решение 4. Отключите антивирус

Вот и все, после выполнения одного из этих исправлений вы сможете установить последнее обновление для вашей сборки Windows 10 Technical Preview.

Если у вас есть какие-либо вопросы, предложения или, возможно, вы знаете другие решения для решения этой проблемы, не забудьте обратиться к разделу комментариев и поделиться своими идеями.

Не смотря на то, что сейчас всё больше и больше пользователей переходят на Windows 10 c Windows 7 или Windows 8.1 тем не менее в корпоративном секторе остаются проблемы: совместимость некоторого ПО (например, КриптоПро) с Windows 10, а так же отсутствие бюджета на обновление лицензий операционной системы.

На днях я решил провести аудит информационных систем в компании и уладить лицензионные вопросы. В частности мне пришлось избавиться от уже привычной Windows 10 на рабочих ПК и вернуть OEM версии ОС, которые были предустановлены при копупке компьютеров. К сожалению, ПК оснащались в то время (2010г) Windows Vista Business и легально проапгрейдить бесплатно до Windows 10 её нельзя (должна быть минимум Windows 7).

Смирившись с этим досадным фактом, я ввёл в домен компании компьютеры на базе Windows Vista Business Edition (версия 6.0.6000).

В нашей доменной организации существует локальный WSUS (Windows Server Update Services), который работает под управлением Windows Server 2012 Standard. Обращаю внимание, что версия сервера без R2, потому что железо относительно старенькое и не поддерживает 2012 R2 из-за устаревшего BIOS. WSUS работает исправно, все компьютеры на базе Windows 7, 8.1 и 10 без проблем получают обновления и рапортуют о своём состоянии.

Теперь переходим к сути данной статьи.

Однако, я заметил, что появилась одна проблемка, компьютер на базе Vista Business почему-то не шлёт WSUS серверу отчет о состоянии. На WSUS постоянно сообщается, что данный компьютер "Not Yet Reported". А так же WSUS определяет и отображает в списке, что на этом компьютере установлена "Windows 6.0" вместо "Windows Vista Business".

При попытке выполнить

wuauclt /detectnow
wuauclt /reportnow

внешне ничего не меняется. Windows Update сообщает, что новых обновлений не найдено. На WSUS обновлений, которые нужно одобрить тоже не появляется.
Если заглянуть в журнал обновлений, то видно, что 3 обновления всё-таки были установлены: два обновления Definition Update for Windows Defender и одно Microsoft Silverlight.

Чтобы разобраться в этой проблеме почитаем лог событий Windows Update.
Стандартно он расположен в C:\Windows\WindowsUpdate.log

Что же там можно увидеть? - Очень много различных записей. Но нас интересуют, прежде всего, записи об ошибках ERROR и FATAL.

Самое начало лога я пропускаю, там никаких серьёзных ошибок не было и трассировки описывали успешность загрузок обновлений в папку C:\Windows\SoftwareDistribution\Download.
Нужно начинать смотреть с ключевого выражения "Logging initialized", обозначающее начало работы службы Windows Update.

2016-06-22 03:28:20:577 1148 bc4 Misc =========== Logging initialized (build: 6.0.6000.16386, tz: +0400) ===========
2016-06-22 03:28:20:640 1148 bc4 Misc = Process: C:\Windows\system32\svchost.exe
2016-06-22 03:28:20:718 1148 bc4 Misc = Module: c:\windows\system32\wuaueng.dll
2016-06-22 03:28:20:577 1148 bc4 Service *************
2016-06-22 03:28:20:796 1148 bc4 Service ** START ** Service: Service startup
2016-06-22 03:28:20:874 1148 bc4 Service *********
2016-06-22 03:28:20:953 1148 bc4 Agent * WU client version 6.0.6000.16386
2016-06-22 03:28:20:953 1148 bc4 Agent * Base directory: C:\Windows\SoftwareDistribution
2016-06-22 03:28:21:031 1148 bc4 Agent * Access type: No proxy
2016-06-22 03:28:21:109 1148 bc4 Agent * Network state: Connected

Из этих данных нам интересна версия агента обновлений, установленного на ПК - WU client version 6.0.6000.16386. Далее скажу зачем.

Смотрим дальше по логу:

Видим, что агент получает настройки для обращения к локальному WSUS и что найдено 98 запросов на возобновление загрузок.
Затем идёт блок с подробным описанием, какие загрузки обновлений возобновляются:

2016-06-22 03:29:06:512 1148 bc4 DnldMgr Download manager restoring 6 downloads
2016-06-22 03:29:06:794 1148 bc4 DtaStor Update service properties: service registered with AU is
2016-06-22 03:29:06:794 1148 bc4 Agent * Succeeded to load 98 persisted download calls
2016-06-22 03:29:06:810 1148 bc4 DnldMgr Retrieved 13 persisted download jobs
2016-06-22 03:29:06:810 1148 bc4 DnldMgr *********** DnldMgr: Restoring download [no. 0] ***********
2016-06-22 03:29:06:810 1148 bc4 DnldMgr * BITS JobId =
2016-06-22 03:29:06:810 1148 bc4 DnldMgr * ServiceId =
2016-06-22 03:29:06:810 1148 bc4 DnldMgr * UpdateId = .101
2016-06-22 03:29:06:935 1148 bc4 DnldMgr * Restored download job.
2016-06-22 03:29:06:935 1148 bc4 DnldMgr *********** DnldMgr: Restoring download [no. 1] ***********
.
2016-06-22 03:29:07:326 1148 bc4 DnldMgr *********** DnldMgr: Restoring download [no. 12] ***********
2016-06-22 03:29:07:326 1148 bc4 DnldMgr * BITS JobId =
2016-06-22 03:29:07:326 1148 bc4 DnldMgr * ServiceId =
2016-06-22 03:29:07:342 1148 bc4 DnldMgr * UpdateId = .101
2016-06-22 03:29:07:373 1148 bc4 DnldMgr * Restored download job.

Видим начало инициализации Автоматического обновления и получения настроек

И инициализацию основных данных для рапорта

2016-06-22 03:29:07:405 1148 bc4 Report *********** Report: Initializing static reporting data ***********
2016-06-22 03:29:07:405 1148 bc4 Report * OS Version = 6.0.6000.0.0.65792
2016-06-22 03:29:07:405 1148 bc4 Report * OS Product Type = 0x00000006
2016-06-22 03:29:07:593 1148 bc4 Report * Computer Brand = R-StyleComputers
2016-06-22 03:29:07:593 1148 bc4 Report * Computer Model = Proxima_
2016-06-22 03:29:07:593 1148 bc4 Report * Bios Revision = ECG3510M.86A.0118.2010.0113.1426
2016-06-22 03:29:07:593 1148 bc4 Report * Bios Name = Default System BIOS
2016-06-22 03:29:07:593 1148 bc4 Report * Bios Release Date = 2010-01-13T00:00:00
2016-06-22 03:29:07:593 1148 bc4 Report * Locale />
Дальше идёт блок трассировки поиска обновлений, где нас ожидают различные проблемы:

Ошибка 0x80244019 описывается как "Серверу не удалось найти запрошенный универсальный код ресурса (URI)".

А перед этим мы замечаем

Ошибка 0x80190194 описывается как "404 - File or directory not found".

Что ещё интересного:

Service WARNING: GetUserTokenFromSessionId failed with error 800703f0 for session 0

Сессия 0 зарезервирована под неинтерактивные (фоновые) пользовательские процессы и службы типа Local System.

И далее замечаем пару строк:

DnldMgr * Update is not allowed to download due to regulation.

Что означает, не разрешено закачивать из-за правил регулирования, то есть либо запрещено политиками обращаться на внешний Windows Update, либо узел перегружен/не доступен.
В моём случае узел сообщал 404 - File or directory not found.

Спрашивается, а почему агент обновлений лезет на внешний узел Windows Update?
Предполагаю, для того чтобы продолжить закачки, которые были прерваны до переключения агента на WSUS, но попытка получить v6odf.xml сведения о регулировании клиентских подключений к системе обновлений, чтобы все пользователи Windows не перегружали узел одновременно заканчиваются провалом, так как такого файла не существует.
Итак, обратиться к внешнему узлу не получилось, едем дальше.

2016-06-22 03:29:10:724 1148 c14 Agent ** START ** Agent: Finding updates [CallerId = AutomaticUpdates]
2016-06-22 03:29:10:724 1148 c14 Agent *********
2016-06-22 03:31:47:659 1148 c14 Handler FATAL: UH: 0x800f0823: CreatePackage failed in CCbs::CreatePackage
2016-06-22 03:31:47:659 1148 c14 Agent WARNING: Failed to evaluate Installed rule, updateId = .1 00, error = 0x80242017
2016-06-22 03:31:47:659 1148 c14 Handler FATAL: UH: 0x800f0823: CreatePackage failed in CCbs::CreatePackage
2016-06-22 03:31:47:659 1148 c14 Agent WARNING: Failed to evaluate Installable rule, updateId = .1 00, error = 0x80242017
2016-06-22 03:31:47:659 1148 c14 Handler FATAL: UH: 0x800f0823: CreatePackage failed in CCbs::CreatePackage
2016-06-22 03:33:11:547 1148 c14 Agent WARNING: Failed to evaluate Installed rule, updateId = .1 01, error = 0x800F0900
2016-06-22 03:33:11:547 1148 c14 Handler FATAL: UH: 0x800f0900: CreatePackage failed in CCbs::CreatePackage
2016-06-22 03:33:11:782 1148 c14 Agent WARNING: Failed to evaluate Installed rule, updateId = .1 01, error = 0x800F0900
2016-06-22 03:33:13:455 1148 c14 Handler FATAL: UH: 0x800f0900: CreatePackage failed in CCbs::CreatePackage
2016-06-22 03:33:13:455 1148 c14 Agent WARNING: Failed to evaluate Installed rule, updateId = .1 01, error = 0x800F0900
2016-06-22 03:33:13:471 1148 c14 Handler FATAL: UH: 0x800f0900: CreatePackage failed in CCbs::CreatePackage
2016-06-22 03:33:18:709 1148 c14 Agent * Found 0 updates and 79 categories in search
2016-06-22 03:33:18:709 1148 c14 Agent *********
2016-06-22 03:33:18:709 1148 c14 Agent ** END ** Agent: Finding updates [CallerId = AutomaticUpdates]

Ошибка 0x800f0823 соответствует 0xf0823 CBS_E_NEW_SERVICING_STACK_REQUIRED (Package needs a newer version of the servicing stack).
Ошибка 0x80242017 означает WU_E_UH_NEW_SERVICING_STACK_REQUIRED (The OS servicing stack must be updated before this update is downloaded or installed).
То есть требуется обновление Обслуживающего стека (OS servicing stack) KB955430.

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

Ошибка 0x800f0900 соответствует 0xf0900 CBS_E_XML_PARSER_FAILURE unexpected internal XML parser error.
То есть возникает какая-то внутренняя ошибка при разборе XML файла. Вероятно, есть проблемы с MSXML Parser (не установлен, старая версия).

И дальше идёт концовка блока проверки обновлений:

Сообщающий о том, что обнаружено 0 обновлений и рапорт был выгружен на WSUS, хотя на самом WSUS никаких сведений о рапорте не получено.

Попробуем выполнить обновление в интерактивном режиме, то есть выполнить команду wuauclt /detectnow и посмотрим лог.

Получаем ту же картину, что и в неинтерактивном режиме: ошибки 0x800f0823 и 0x800F0900.

2016-06-22 02:48:10:100 1148 6e0 Report REPORT EVENT: 2016-06-22 02:48:05:099+0400 1 147 101 0 0 AutomaticUpdates Success Software Synchronization Windows Update Client successfully detected 0 updates.
2016-06-22 02:48:10:100 1148 6e0 Report REPORT EVENT: 2016-06-22 02:48:05:099+0400 1 153 101 0 0 AutomaticUpdates Success Pre-Deployment Check Reporting client status.

Видно, что агент посылает рапорт, но WSUS его либо не получает, либо не понимает. И ещё странно, что WSUS не понимает, что у меня на ПК установлена Windows Vista, а определяет её как Windows 6.0.

Вначале я погуглил.
Предлагалось выполнить wuauclt /resetauthorization /detectnow но это не помогло.
Предлагалось проверить настройки IIS, но всё было корректно.
Предлагалось кардинально переустановить WSUS, но я был не согласен в виду того, что другие ПК без проблем получают обновления.

Я решил пойти для начала самым простым и логичным способом - попробовать обновить агент обновлений WUA в надежде, что свежая версия агента корректно работает с последней версией WSUS и избавлен от багов. Как мы видели выше, текущая версия агента WU client version 6.0.6000.16386.

На данный момент последняя версия WUA - The latest version of the Windows Update Agent for Windows 7, Windows Vista, and Windows XP is 7.6.7600.256.

После установки новой версии WUA мой WSUS начал правильно определять, что на ПК установлена Windows Vista Business и стал получать рапорты состояния в результате чего WSUS определил какие обновления необходимы для данного ПК.

В логе теперь пишется версия WU client version 7.4.7600.226:

2016-06-22 22:20:17:756 1156 580 Service ** START ** Service: Service startup
2016-06-22 22:20:17:756 1156 580 Service *********
2016-06-22 22:20:18:100 1156 580 Agent * WU client version 7.4.7600.226
2016-06-22 22:20:18:100 1156 580 Agent * Base directory: C:\Windows\SoftwareDistribution
2016-06-22 22:20:18:100 1156 580 Agent * Access type: No proxy
2016-06-22 22:20:18:115 1156 580 Agent * Network state: Connected

Далее видим, что в новой версии изменился путь до файла сервера регулирования (Regulation server)

Видим, что приостановленные закачки успешно закачивают обновления с внешнего Windows Update:

Но, несмотря на значительные подвижки, мы пока всё ещё видим ошибки 0x800f0823 и 0x800f0900:

Переходим к WSUS и проверяем какие обновления требует наша Windows Vista Business.
Обнаруживаем 151 обновление для Vista и одобряем их установку. Через некоторое время Windows Vista обнаруживает обновления и предлагает их установить.

  • Вызываем командную строку, зажимая WIN+R, вводя cmd и выбирая Запуск от имени администратора
  • в появившемся окне консоли вводим последовательно две следующие команды:

ошибка 0x80240017

Это остановит службы Центра обновления и Фоновую интеллектуальную службу передачи

C:\Windows\SoftwareDistribution

и удаляем всё её содержимое. Эта папка используется системой для временного хранения файлов, которые используются для обновления Windows и поддерживаются агентом WUAgent. Если проводник или некоторые службы будут использовать некоторые из файлов, на некотором этапе система выдаст ошибку удаления. Это нормально. Для полного удаления следует либо перезагрузить Windows, либо воспользоваться программой Unlocker.

  • В другом варианте можно попытаться не удалять файлы, а переименовать саму папку, оставляя содержимое про запас. Это можно сделать в том же окне консоли командой:
  • После удаления содержимого папки или её переименования перезагрузите систему. Снова вызываем консоль команд Windows в правами админа и проверяем, запущены ли остановленные сервисы:

Ждём обновления Windows или принудительно просим систему обновиться. Windows скачает недостающие файлы или заново воссоздаст папку под нужным именем. Проверяем и отписываемся.

Что за папка и безопасно ли удалять её содержимое?

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

У меня перестали устанавливаться обновления на Windows 10. Точнее, всякая мелочь благополучно вставала, но нажористый feature update под номером 2004 благополучно скачивался, что-то там делал, но после перезагрузки номер версии не менялся. В Центре обновлений появлялось уведомление об ошибке 0x80242016 и предложение попробовать еще разок.

Сначала я не обращал на это внимание. Обновление получилось несколько глючным, и Microsoft даже отзывала его на переделку. Но потом все наладилось. На тестовый ноутбук HP Elite Dragonfly версия 2004 встала с полпинка, и я стал с подозрением смотреть на большой компьютер. С одной стороны, фиг бы с ним, с этим обновлением. Ничего действительно серьезного в нем нет, переживу. С другой, очень раздражает, когда в компьютере что-то глючит. Даже по мелочи. Как показывает опыт, постепенно это перерастает во что-то большее. А я еще апгрейд планирую через недельку…

В общем, решил заняться багом всерьез. Как показало глубокое гугление, ошибка 0x80242016 известна довольно давно, и причин ее появления может быть немало. Иногда виноват сам механизм Windows Update, иногда сходила с ума служба Windows Search. Соответственно, рецептов борьбы с ошибкой в интернете тьма. От банальной рекомендации перезагрузить компьютер до шаманства в терминале по тотальному сбросу настроек Центра обновлений. Один из ярких примеров подборок рецептов здесь . Я перепробовал абсолютно все. Не помогло.

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

И когда отчаяние уже печально дышало в затылок, я нашел первопричину проблемы. Как ни странно, на сайте самой Microsoft . Оказывается, обновление 2004 конкретно параноит по поводу загрузчика Windows, а конкретно насчет BCD (Boot Configuration Data). Если вы с ним что-то делали, даже самое невинное, обновление обидится, но вам не скажет.

А я ведь делал. Когда менял SSD на модель с поддержкой PCIe 4.0 , переносил на него данные путем полного клонирования. С тех пор прошло, на минуточку, больше полугода, и операционная система работала безупречно. Но в версии 2004 решила психануть.

Сделать новую BCD, в общем, не очень сложно. Особенно в Windows 10, где эта процедура упростилась. Но все же надо соорудить загрузочный носитель, загрузиться с него и через командную строку дать ценные указания. Я использовал вот этот рецепт . Тут еще был нюанс, что простое “пересоздание” не помогает, надо удалить старую BCD, и потом с нуля делать новую.

Не скажу, что процесс прямо сложный. Но для нормального человека несколько… нервный, потому что все надо набирать командами. Иногда довольно длинными. Опечатаешься – и сидишь, ломаешь голову, что сделал не так. Конечно, при некоторой внимательности опечаток можно избежать, но у меня на часах была уже полночь, а за спиной целый день экспериментов.

В итоге все получилось. Новая BCD заработала, обновление скачалось и встало, как положено.

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

В ходе экспериментов восстановил участие в программе Windows Insider, и теперь мне предлагают поставить сборку 20H2. Но что-то опасаюсь…

Читайте также: