В предыдущей статье данного цикла мы познакомились с подсистемой Event Tracing For Windows. Настоящая и последующая статьи этого цикла посвящены платформе Windows Troubleshooting Platform, которая впервые появилась в операционной системе Windows 7.
Платформа Windows Troubleshooting Platform представляет собой средство для выполнения специальных модулей (Troubleshooting Packages), которые создаются на языке PowerShell и призваны решать различные проблемы, касающиеся конфигурации операционной системы, ее отдельных компонентов, устройств, сервисов и приложений. Эти модули могут вызываться как пользователями, так и приложениями при возникновении определенных проблем и проводят пользователей через серию шагов для их решения: обнаружение проблемы, устранение проблемы, проверка отсутствия проблемы. Например, если Windows Internet Explorer не может открыть вебсайт, пользователь нажимает кнопку Diagnose Connection Problems для запуска модуля Windows Network Diagnostics, реализованного на платформе Windows Troubleshooting Platform.
Подход, ориентированный на предоставление конечным пользователям средств решения различных проблем, связанных с настройкой операционной системы, сервисов и приложений, может существенно уменьшить число обращений в службу технической поддержки, сделать такие звонки более эффективными и в целом повысить удовлетворенность пользователей.
К основным характеристикам платформы Windows Troubleshooting Platform относятся возможность ее автоматизации, эффективность, повторяемость операций, стандартизация и безопасность. Расширяемость платформы означает, что в состав Windows Software Development Kit (SDK) входят средства, позволяющие разработчикам создавать новые модули для этой платформы, что дает возможность использовать ее в качестве унифицированного механизма для настройки необходимого окружения для приложений сторонних компаний (ISV).
Далее мы рассмотрим стандартные модули, включенные в состав операционной системы Windows 7, принципы их работы, архитектуру Windows Troubleshooting Platform, средства создания дополнительных модулей и приведем ряд примеров создания собственных модулей для платформы Windows Troubleshooting Platform.
Встроенные модули
В состав операционной системы Windows 7 входит ряд модулей, которые соответствуют десяти наиболее частым категориям обращений в службу технической поддержки Microsoft, включая эффективное управление питанием, совместимость приложений, сетевые настройки и настройки звука. В табл. 1 перечислены модули платформы Windows Troubleshooting Platform, имеющиеся в составе Windows 7.
Модули платформы Windows Troubleshooting Platform доступны через панель управления: Control Panel → All Control Panel Items → Troubleshooting. Модули сгруппированы по категориям: Programs, Hardware and Sound, Network and Internet, Appearance and Personalization и System and Security.
Обратите внимание на то, что запуск некоторых модулей требует привилегий администратора, тогда как большинство модулей доступно для запуска обычным пользователям.
Модули платформы Windows Troubleshooting Platform в панели управления
В нижней части панели расположена опция, включение которой позволяет получать обновления модулей от специального сервиса — Windows Online Troubleshooting Service.
Модули — это специальные приложения, запускаемые под управлением платформы Windows Troubleshooting Platform. Модули, поставляемые в составе операционной системы Windows 7, располагаются в каталоге %windir%\Diagnostics. Каталог %windir%\Diagnostics\Index содержит XML-манифесты модулей, а каталог %windir%\Diagnostics\System — сами модули, находящиеся в соответствующих подкаталогах.
Модули платформы Windows Troubleshooting Platform на диске
Внутри каждого подкаталога есть файл DiagPackage.diagpkg, представляющий собой соответствующий модуль, а также динамическую библиотеку DiagPackage.dll, каталог с интерфейсными ресурсами и ряд исходных файлов на PowerShell, которые иллюстрируют работу данного модуля. Двойной щелчок мышью по файлу DiagPackage.diagpkg приводит к запуску соответствующего модуля — это то же самое, что активация модуля непосредственно из панели управления.
Как мы отметили выше, каждый модуль проводит пользователей через серию шагов для их решения: обнаружение проблемы (Detection), устранение проблемы (Resolution), проверка отсутствия проблемы (Verification). Далее мы рассмотрим работу основных системных модулей и предпринимаемые ими шаги по решению тех или иных проблем.
Работа основных системных модулей
На уровне операционной системы не существует единого источника данных, позволяющего получать информацию в случае возникновения той или иной проблемы. Однако множество источников данных дает возможность гибко выбрать именно те данные, которые наиболее точно отражают причины той или иной проблемы. При создании модулей нужно использовать наиболее простые и сфокусированные на проблеме источники данных, доступ к которым требует минимального кодирования, а также источники, которые будут доступны на большинстве компьютеров. При создании модулей следует руководствоваться следующими категориями источников данных, перечисленных в порядке от наиболее к наименее рекомендуемым:
Ниже мы приведем несколько примеров использования этих источников данных для решения ряда наиболее часто возникающих проблем. Проблемы сгруппированы по категориям — в каждой категории показаны основные причины их возникновения. Информация разделена на три группы: определение проблемы, исправление проблемы и проверка отсутствия проблемы. В большинстве случаев проверка отсутствия проблемы представляет собой те же действия, что и определение проблемы, поскольку используется одна и та же логика. Тем не менее в ряде случаев такой подход невозможен. Например, при устранении проблем, связанных с воспроизведением звука, при обнаружении низкого уровня звука пользователь может увеличить этот уровень, но программным образом нельзя проверить, была ли после этого устранена проблема. Поэтому в ряде случаев решение проблемы возлагается на пользователей. Например, если основной проблемой с воспроизведением видео является видеокарта с отсутствующими характеристиками, то решением проблемы становится либо установка обновленного драйвера, либо замена видеокарты — и ту и другую операцию невозможно выполнить автоматически.
Использование подсистемы Aero
В данной группе проблемы, связанные с отображением анимации и эффектов, устраняются с помощью подсистемы Aero (табл. 2).
Средство устранения неполадок в Центре обновления Windows 10
Windows 10 Update Troubleshooter является улучшенной версией инструмента устранения проблем предыдущих версий Windows. Утилита проверяет работоспособность службы Windows Update и фоновой интеллектуальной службы передачи (BITS), а также выполняет диагностику сетей Windows.
Рекомендуется перейти в расширенные настройки, нажав по ссылке “Дополнительно” и отключить опцию “Автоматически применять исправления”. Это позволит получить полный контроль над процессом восстановления.
После быстрого сканирования в случае обнаружения проблемы, инструмент выводит список доступных опций:
Как можно видеть, инструмент самостоятельно обнаруживает неисправность и может устранить некоторые из них по согласию пользователя или автоматически.
Если не помогло?
1. Рекомендуется найти самое последнее установленное обновление для Windows 10 и выполнить поиск этого обновления на сайте Microsoft Update Catalog. Скачайте и установите его заново.
2. Если это не сработало, то пользователь должен запустить следующую команду в командной строке:
В предыдущей статье данного цикла мы начали знакомство с платформой Windows Troubleshooting Platform и рассмотрели ряд примеров работы системных модулей. Настоящая статья, завершающая данный цикл, посвящена архитектуре платформы Windows Troubleshooting Platform и модулей.
Архитектура платформы
Платформа Windows Troubleshooting Platform состоит из трех основных компонентов: Windows Troubleshooting Framework, приложения, выполняющегося в процессе 1, и модуля Troubleshooting Pack. Архитектура платформы показана на диаграмме, приведенной на рис. 1.
Рис. 1. Архитектура платформы Windows Troubleshooting Platform
На диаграмме обозначены границы процессов, где PowerShell выполняется в отдельном от платформы Windows Troubleshooting Platform процессе. Это сделано для обеспечения надежности и для изоляции сценариев от возможных эффектов выполнения команд и пользовательского интерфейса.
Windows Troubleshooting Platform
Как показано на диаграмме, Windows Troubleshooting Platform состоит из ядра времени выполнения (run-time engine), средства отображения результатов и отчетов, ряда специальных командлетов и ядра времени выполнения для Windows PowerShell. Когда пользователь или приложение запускает модуль, ядро времени выполнения считывает метаданные из модуля, проверяет цифровую подпись и отображает интерфейс пользователя. После этого запускается сценарий на PowerShell, который определяет наличие проблемы. Если сценарию необходимо взаимодействие с пользователем, запускаются соответствующие дополнительные командлеты.
Графический и командный интерфейс
Модули могут быть запущены как через графический интерфейс, так и из командной строки. Графический интерфейс предназначен для конечных пользователей, тогда как интерфейс командной строки чаще всего применяется администраторами.
Модуль
Модуль состоит из метаданных и набора сценариев на PowerShell, которые используются для обнаружения проблемы, ее исправления и проверки выполненных действий. Локализация осуществляется с помощью стандартных ресурсных файлов — Multiple-Language UI (MUI) resource file. Для их безопасного выполнения модули должны содержать цифровую подпись. Устройство модуля показано на диаграмме (рис. 2).
Рис. 2. Устройство модуля
Из следующего раздела мы узнаем, как создавать собственные модули с помощью специального средства, входящего в состав Windows 7 Software Development Kit (SDK).
Создание собственных модулей
Для создания собственных модулей, расширяющих возможности платформы Windows Troubleshooting Platform и позволяющих решать дополнительные задачи по настройке приложений, применяется специальный редактор, входящий в состав Windows 7 Software Development Kit. Он называется Troubleshooting Pack Builder и после установки Windows SDK обычно находится в папке %programfiles%\Microsoft SDKs\Windows\v7.0\ Bin\TSPBuilder. Обновленную версию дизайнера модулей можно загрузить с сайта Microsoft по адресу: https://connect.microsoft.com/site919.
В нашем примере мы создадим модуль, который будет решать довольно простую задачу — включение отображения строки состояния в утилите Notepad. Для того чтобы мы могли создать наш демонстрационный модуль, необходимо выполнить два подготовительных действия. Вопервых, нужно сконфигурировать PowerShell таким образом, чтобы мы могли выполнять неподписанные сценарии. Для этого следует запустить PowerShell от лица администратора (Run As Admin) и ввести следующую команду:
Вовторых, необходимо запустить сценарий TestModeSetup, который находится в том же каталоге, что и дизайнер модулей, — это позволит нам тестировать сценарии модулей в контексте PowerShell и использовать дополнительные командлеты, входящие в состав Windows Troubleshooting Platform. В PowerShell необходимо выполнить команду File → Open и перейти в каталог %programfiles%\Microsoft SDKs\Windows\v7.0\Bin\TSPBuilder, выбрать в нем сценарий TestModeSetup.ps1 и выполнить его в среде PowerShell, нажав клавишу F5.
Теперь мы готовы к созданию нашего первого модуля для платформы Windows Troubleshooting Pack. Запустим дизайнер Troubleshooting Pack Builder — TSPDesigner.exe. Выполним команду Project → New — это приведет к созданию нового проекта. На первом шаге нужно задать имя проекта — в нашем примере это будет NotepadFix. Обратите внимание на то, что по умолчанию создаваемые модули сохраняются в пользовательском профиле — в каталоге %userprofile%\documents\troubleshooting packs.
Проекты создаются в папках, соответствующих именам проекта, сохраняются в файлах с расширением *.diag и представляют собой XML-файлы с описанием свойств проекта и ссылки на сценарии PowerShell, выполняющие обнаружение проблемы, ее исправление и проверку внесенных изменений. Эти файлы используются для компиляции модуля на этапе его сборки.
В свойствах проекта мы указываем следующую информацию: название, описание и ссылку на информацию о сохранении данных. В нашем примере мы зададим следующие значения:
После этого следует выполнить команду Add New Root Cause в панели в левой части дизайнера (рис. 3). Это приведет к появлению панели, описывающей основную проблему (root cause), — здесь нам необходимо указать следующие значения:
Рис. 3. Свойства проекта
Идентификатор основной проблемы (Root Cause ID) будет применяться в сценариях на PowerShell и в тех случаях, когда модуль решает более одной проблемы, при этом он должен иметь уникальное в рамках данного модуля значение. Два других поля носят описательный характер, и их значения отображаются в соответствующих местах пользовательского интерфейса.
Элемент Root Cause имеет ряд дополнительных элементов: Troubleshooter, Resolver, Verifier и Scripts. Элемент Troubleshooter описывает характеристики процесса обнаружения проблемы, элемент Resolver — ее решение, элемент Verifier — шаги по проверке внесенных изменений, а элемент Scripts обеспечивает связь проекта со сценариями на PowerShell.
Для нашего примера для элемента Troubleshooter укажем, что повышение привилегий не требуется (Elevation = False) и что при обнаружении проблемы нет необходимости во взаимодействии с пользователем (Interactions = False). Для элемента Resolver укажем имя сценария на PowerShell — RS_EnableStatusBar и зададим значения False для опций Prompt the User, Elevation и Interactions; для элемента Verifier укажем, что проверка внесенных изменений возможна (Verifiable = True) и что для этой проверки мы будем использовать тот же сценарий, что и для обнаружения проблемы (Reuse Troubleshooter = True).
После этого можно переходить на страницу Root Cause Scripts, которая содержит ссылки на два сценария на PowerShell: Troubleshooter и Resolver. Поскольку проверка внесенных изменений аналогична определению наличия проблемы, отдельный сценарий для элемента Verifier не нужен.
В разделе Troubleshooter щелкнем по команде Edit Troubleshooter Script и в среде PowerShell введем следующий код:
Здесь мы применяем два дополнительных командлета, предоставляемых платформой Windows Troubleshooting Platform: Write-DiagProgress и Update-DiagRootCause. Командлет Write-DiagProgress используется для уведомления пользователей о выполняемых действиях и имеет два параметра: Activity, описывающий действия, и Status, описывающий состояние операции. Командлет Update-DiagRootCause служит для обновления статуса основной проблемы — обнаружена она на шаге идентификации или нет. Собственно проверка наличия проблемы сводится к обращению к записи Statusbar в соответствующей ветви реестра и определении ее текущего значения — если оно не равно 1, значит, строка состояния отключена и проблема существует.
Сохраним наш код, закроем PowerShell и вернемся в дизайнер модулей. В разделе Resolver щелкнем по команде Edit Troubleshooter Script и в среде PowerShell введем следующий код:
# Внести необходимые изменения
Здесь мы также применяем командлет Write-DiagProgress для уведомления пользователей о выполняемых действиях, а затем изменяем значение записи Statusbar в соответствующей ветви реестра. Сохраним наш код, закроем PowerShell и вернемся в дизайнер модулей. Мы успешно создали наш первый модуль для платформы Windows Troubleshooter Platform. Нам осталось выполнить команду Build → Build Pack для сборки модуля, а затем команду Build → Run для его запуска. В процессе сборки модуля будет сгенерирована тестовая цифровая подпись, которую можно использовать при создании и отладке модулей на локальном компьютере.
Запустим наш модуль и убедимся в том, что он определяет наличие проблемы (отключение отображения строки состояния в Notepad — рис. 4) и исправляет ее (рис. 5).
Рис. 4. Запуск модуля NotepadFix
Рис. 5. Результат работы модуля NotepadFix
После того как мы получили представление о том, как устроены, создаются и работают модули для платформы Windows Troubleshooting Platform, можно обратиться к стандартным модулям, поставляемым в составе операционной системы WIndows 7, и более детально ознакомиться с их работой. Напомним, что модули располагаются в каталоге %windir%\Diagnostics в соответствующих подкаталогах. Файлы сценариев PowerShell с префиксом TS_ содержат код для определения проблемы, с префиксом RS_ — код ее устранения. В некоторых каталогах также присутствуют файлы сценариев PowerShell с префиксом CL_ — в них содержится общий код, полезные функции, прототипы вызовов функций Windows API и т.п.
Заключение
В этой статье мы завершили знакомство с платформой Windows Troubleshooting Platform, которая впервые появилась в Windows 7 и служит универсальным средством для решения широкого спектра проблем, связанных с настройкой операционной системы, ее компонентов, сервисов и приложений. Напомним, что платформа Windows Troubleshooting Platform поддерживает расширяемость — разработчики могут создавать собственные модули для решения проблем, связанных с конфигурацией приложений, и распространять их по электронной почте или через соответствующие разделы вебсайтов.
Ресурсы для устранения неполадок интегрированной среды разработки Resources for troubleshooting IDE errors
Не все сообщения об ошибках имеют отдельный соответствующий раздел справки. Not all error messages have a specific associated Help topic. Если описание сообщения об ошибке не помогло решить проблему, вы можете обратиться к другим ресурсам, таким как статьи базы знаний, форумы или служба технической поддержки. If the information in an error message doesn’t help you resolve the problem, you can consult other resources such as Knowledge Base articles, forums, or product support.
Этот раздел относится к Visual Studio в Windows. This topic applies to Visual Studio on Windows. Информацию о Visual Studio для Mac см. в статье Устранение неполадок Visual Studio для Mac. For Visual Studio for Mac, see Troubleshoot Visual Studio for Mac.
Статьи базы знаний Knowledge Base articles
Вы можете искать сведения о проблемах с продуктами в статьях базы знаний (KB) через Интернет. You can search the Knowledge Base (KB) online for articles about product issues. Не все проблемы снабжены статьями в базе знаний, но обычно ошибки, возникающие у значительного числа пользователей, документируются. Not all issues have a corresponding KB article, but errors encountered by a significant number of customers are typically documented. Статьи базы знаний по Visual Studio можно также просмотреть на странице сведений об устранении неполадок Visual Studio. You can view KB articles for Visual Studio on the Visual Studio troubleshooting page.
Форумы разработчиков Developer forums
Форумы позволяют взаимодействовать с другими разработчиками, а также с сотрудниками корпорации Майкрософт. Forums let you interact with other developers, and also Microsoft employees. Если вы столкнулись с ошибкой и не можете найти решение, можно задать вопрос о ней на форуме. If you encounter an error that you cannot find a resolution for, you can post questions about the issue on a forum. Можно также выполнить поиск по форумам, чтобы узнать, не публиковал ли кто-то другой материалы о подобной проблеме. You can also search the forums to see whether others have posted about the same issue.
Ниже приведен список ресурсов форумов: Here’s a list of forum resources:
Поддержка продуктов Product support
Если у вас остались вопросы после ознакомления с другими ресурсами, вы можете обратиться в службу поддержки Майкрософт, посетив веб-сайт поддержки Майкрософт. If you still have questions after you try the other resources, you can contact Microsoft support services by visiting the Microsoft Support website. Сведения о поддержке продуктов, доступной в вашем регионе, см. в разделе Параметры обратной связи Visual Studio. For information about product support available in your area, see the Visual Studio feedback options page.
Оригинальная версия продукта: Windows 10 — все версии, Windows Server 2019, Windows Server 2012 R2 Оригинальный номер базы знаний: 2734782
Решения для Windows Server
Код ошибки 0x800F0906
Данный код ошибки возникает потому, что компьютер не может скачать необходимые файлы из Центра обновления Windows.
Для решения этой проблемы воспользуйтесь одним из указанных ниже способов.
Способ 1: Проверьте подключение к Интернету
Данная реакция может быть вызвана настройками или сбоями сети, прокси или брандмауэра. Чтобы устранить проблему, попробуйте открыть веб-сайт Центра обновления Windows.
Если он недоступен, проверьте подключение к Интернету или обратитесь к сетевому администратору, чтобы определить, не блокирует ли доступ к веб-сайту какая-либо настройка.
Способ 2: Настройте параметр групповой политики
Это поведение может быть вызвано также тем, что системный администратор настроил обслуживание компьютера через службу Windows Server Update Services (WSUS), а не через сервер Центра обновления Windows. В этом случае обратитесь к системному администратору и попросите включить параметр групповой политики Укажите параметры для установки необязательных компонентов и восстановления компонентов, а также настроить значение Альтернативный путь к исходным файлам либо выбрать параметр Для загрузки содержимого для восстановления перейдите непосредственно в Центр обновления Windows вместо служб обновления Windows Server (WSUS).
Чтобы настроить данный параметр групповой политики, выполните следующие действия:
Запустите редактор локальных групповых политик или консоль управления групповыми политиками.
Наведите указатель на правый верхний угол экрана, нажмите кнопку Поиск, введите запрос «групповая политика» и выберите Изменение групповой политики.
Последовательно разверните узлы Конфигурация компьютера, Административные шаблоны и Система. Снимок экрана для этого этапа приведен ниже.
Откройте параметр групповой политики Укажите параметры для установки необязательных компонентов и восстановления компонентов и выберите Включено. Снимок экрана для этого этапа приведен ниже.
Чтобы выбрать альтернативный исходный файл, в поле Альтернативный путь к исходным файлам укажите полный путь к общей папке с содержимым папки \sources\sxs установочного носителя.
Пример пути к общей папке: \\server_name\share\Win8sxs
Или укажите WIM-файл. Чтобы задать в качестве места расположения альтернативного исходного файла WIM-файл, добавьте к пути префикс WIM:, а затем укажите в качестве суффикса индекс образа, который вы хотите использовать в WIM-файле.
Пример пути к WIM-файлу: WIM:\\server_name\share\install.wim:3
В данном примере 3 — это индекс образа, в котором хранятся файлы компонента.
Если необходимо, установите флажок «Для загрузки содержимого для восстановления перейдите непосредственно в Центр обновления Windows вместо служб обновления Windows Server (WSUS)«.
Нажмите кнопку ОК.
В командной строке с повышенными привилегиями введите gpupdate /force и нажмите клавишу Ввод, чтобы сразу применить политику:
Способ 3: Используйте установочный носитель Windows
Вставьте установочный носитель Windows.
Из командной строки с повышенными привилегиями запустите следующую команду:
В этой команде является заполнителем для буквы дисковода DVD-дисков. Например, выполните следующую команду:
Способ 4: Альтернативные шаги для Windows Server
В Windows Server 2012 R2 можно также указать альтернативный источник, используя командлеты Windows PowerShell или мастер добавления ролей и компонентов.
Чтобы использовать Windows PowerShell, выполните следующие действия.
Вставьте установочный носитель Windows.
Из командной строки с повышенными привилегиями Windows PowerShell запустите следующую команду:
В этой команде является заполнителем для буквы дисковода DVD-дисков или установочного носителя Windows. Например, выполните следующую команду:
Чтобы использовать мастер добавления ролей и компонентов, выполните следующие действия:
Вставьте установочный носитель Windows.
Запустите мастер добавления ролей и компонентов.
На странице Подтверждение установки компонентов щелкните ссылку Указать альтернативный исходный путь. Снимок экрана для этого этапа приведен ниже.
На странице Указать альтернативный исходный путь введите путь к папке SxS в виде локального пути или пути к сетевой общей папке. Снимок экрана для этого этапа приведен ниже.
Нажмите кнопку ОК.
Нажмите кнопку Установить, чтобы завершить работу мастера.
Код ошибки 0x800F081F
Этот код ошибки может возникнуть, если указан альтернативный источник установки и выполнено одно из перечисленных ниже условий.
Чтобы устранить эту проблему, убедитесь, что полный путь к источнику указан верно ( x:\sources\sxs ) и у вас есть доступ к расположению хотя бы на чтение. Для этого попытайтесь обратиться к источнику непосредственно с компьютера, на котором возникла проблема. Убедитесь, что источник установки содержит допустимый и полный набор файлов. Если проблема не исчезнет, воспользуйтесь другим источником установки.
Код ошибки 0x800F0907
Данный код ошибки возникает, если альтернативный источник установки не задан или недействителен, а параметр групповой политики Укажите параметры для установки необязательных компонентов и восстановления компонентов имеет значение «Не пытайтесь загрузить полезные данные из центра обновления Windows».
Чтобы устранить эту проблему, изучите параметр политики и определите, подходит ли он для вашей среды. Если вы не хотите загружать полезные данные компонентов из Центра обновления Windows, попробуйте настроить для параметра групповой политики значение Альтернативный путь к исходным файлам.
Чтобы менять параметры групповой политики на локальном компьютере, необходимо быть членом группы администраторов. Если параметры групповой политики для данного компьютера задаются на уровне домена, обратитесь к своему системному администратору.
Для этого выполните следующие действия:
Запустите редактор локальных групповых политик или консоль управления групповыми политиками (в зависимости от вашей среды).
Последовательно разверните узлы Конфигурация компьютера, Административные шаблоны и Система.
Откройте параметр групповой политики Укажите параметры для установки необязательных компонентов и восстановления компонентов и выберите Включено.
Определите, включен ли параметр групповой политики Не пытайтесь загрузить полезные данные из центра обновления Windows, а затем установите нужный параметр для своей среды.
Чтобы выбрать альтернативный исходный файл, в поле Альтернативный путь к исходным файлам укажите полный путь к общей папке с содержимым папки \sources\sxs установочного носителя. Или укажите WIM-файл. Чтобы задать в качестве места расположения альтернативного исходного файла WIM-файл, добавьте к пути префикс WIM:, а затем укажите в качестве суффикса индекс образа, который вы хотите использовать в WIM-файле. Ниже приведены примеры возможных значений:
Если хотите, установите флажок Для загрузки содержимого для восстановления перейдите непосредственно в Центр обновления Windows вместо служб обновления Windows Server (WSUS).
Нажмите кнопку ОК.
В командной строке с повышенными привилегиями введите gpupdate /force и нажмите клавишу Ввод, чтобы сразу применить политику.
Решение для Windows 10
Коды ошибок 0x800F0906, 0x800F081F или 0x800F0907
Для исправления ошибок с этими кодами в Windows 10 выполните следующие действия.
Скачайте средство создания носителей Windows и создайте образ ISO локально либо создайте образ для установленной версии Windows.
Настройте групповую политику, как описано в способе 2, а также выполните следующие действия:
Код ошибки 0x800F0922
При обновлении Windows 10 появляется следующее сообщение об ошибке:
0x800F0922 CBS_E_INSTALLERS_FAILED: ошибка обработки дополнительных программ установки и общих команд.
Для устранения данной проблемы выполните следующие действия.
Откройте папку Sources.
Щелкните папку SXS правой кнопкой мыши и выберите пункт Свойства.
Выберите вкладку Безопасность и убедитесь, что флажок у параметра Чтение и выполнение установлен. Если флажка нет, нажмите кнопку Изменить и установите его.
Нажмите клавиши Windows + X.
Выберите пункт Командная строка (Администратор).
В окне командной строки введите указанную ниже команду и нажмите клавишу «Ввод».
В окне командной строки введите указанную ниже команду и нажмите клавишу «Ввод».
Дополнительная информация
Сообщения об ошибках, связанные с этими кодами ошибок
Windows не удалось применить требуемые изменения. Windows не удалось подключиться к Интернету, чтобы скачать необходимые файлы. Проверьте подключение и попробуйте еще раз, нажав кнопку Повторить.
Сбой установки одной или нескольких ролей, служб ролей или компонентов. Не удалось найти исходные файлы. Попробуйте установить роли, службы ролей или компоненты еще раз в новом сеансе мастера добавления ролей и компонентов и выберите на странице подтверждения параметр Указать альтернативный исходный путь, чтобы указать действительное расположение исходных файлов, необходимых для установки. Расположение должно быть доступно для учетной записи компьютера конечного сервера.
Код ошибки: 0x800F0906
Код ошибки: 0x800F081F
Ошибка: 0x800F081F
0x800F0907
Сбой DISM. Операция не выполнена. Дополнительные сведения см. в файле журнала. Файл журнала DISM находится по адресу C:\Windows\Logs\DISM\dism.log
Из-за параметров политики сети Windows не удалось подключиться к Интернету, чтобы скачать файлы, необходимые для выполнения запрошенных изменений. За дополнительными сведениями обратитесь к администратору сети.
