Сбой службы активации процессов Windows - Windows 10

9

Служба активации процессов Windows (WAS) больше не запускается на моем ПК с Windows 10. В результате IIS не запускается. Я не совсем уверен, когда это произошло, но, скорее всего, в прошлом месяце.

Во время запуска я теперь получаю серию из 4 ошибок в системном журнале:

WAS 5215: Служба активации процессов Windows (WAS) не смогла выполнить инициализацию для автономной установки. Поле данных содержит номер ошибки. [Поле данных: 50000780]

WAS 5005. Служба активации процессов Windows (WAS) останавливается, поскольку обнаружена ошибка. Поле данных содержит номер ошибки. [Поле данных: 50000780]

Диспетчер управления службами 7023. Служба WAS прервана из-за следующей ошибки: файл существует.

Диспетчер управления службами 7001: служба W3SVC зависит от службы WAS, которую не удалось запустить из-за следующей ошибки: файл существует.

У меня не так много ссылок на этот тип ошибки, поскольку файл существует .

(Я пытался использовать ProcMon, чтобы попытаться определить, на какой файл он ссылается, но он абсолютно отказывается запускаться.)


Edit ... наконец-то заставил ProcMon работать (после распаковки 64-битной версии с использованием VS2017). Оказывается, что файл, который был причиной вышеупомянутой проблемы, был файлом "applicationhost.config.tmp" в C:\Windows\System32\inetsrv\Configпапке. Удаление этого файла позволило продолжить процесс.

Теперь первая и третья ошибки:

WAS 5215: Служба активации процессов Windows (WAS) не смогла выполнить инициализацию для автономной установки. Поле данных содержит номер ошибки. [Поле данных: 0D000780]

Диспетчер управления службами 7023. Служба активации процессов Windows прервана из-за следующей ошибки: Данные недействительны.


Согласно ответу Янбинга Ши, вот самые последние строки из iis.logфайла:

[01/13/2018 23:10:41] [ ***** IIS 10.0 Component Based Setup ***** ] [01/13/2018 23:10:41] .\inetsrv\iissetup.exe /install SharedLibraries /nano [01/13/2018 23:10:41] Setting Installation Type to Nano [01/13/2018 23:10:41] Successfully added IIS_IUSRS ACE to DACL at %ProgramData%\Microsoft\Windows\WER\ReportQueue. [01/13/2018 23:10:42] < !!FAIL!! > Failed to create the NetFrameworkConfigurationKey key container (result=0x8009000f) [01/13/2018 23:10:42] < !!FAIL!! > Install of component SharedLibraries result=0x8009000f [01/13/2018 23:10:42] < !!FAIL!! > COMPONENT::ExecuteCommand result=0x8009000f [01/13/2018 23:10:42] [ End of IIS 10.0 Component Based Setup ]


В ответ на следующий ответ Янбин Ши ...

Сначала я не смог просмотреть / отредактировать / удалить d6d986f09a1ee04e24c949879fdb506c_*файл. Когда я попытался просмотреть его разрешение, я получил сообщение: You do not have permission to view this object's security properties, even as an administrative user. я, однако, смог сменить владельца на «Администраторы», затем дать Fullразрешение этой группе , и затем я смог его просмотреть. Файл не был текстовым файлом, но около 28 байт в файле NetFrameworkConfigurationKey. Я переместил файл из этой папки.

Я тогда побежал net start wasи получилSystem error 80 has occurred. The file exists.

В iis.logфайл ничего не было добавлено, но в журнал системных событий были добавлены обычные события ошибок.

Затем я вручную удалил applicationhost.config.tmpфайл и запустился net start was. На этот раз я получилSystem error 13 has occurred. The data is invalid.

На этот раз появились новые записи iis.log

[03/18/2018 07:44:54] [ ***** IIS 10.0 Component Based Setup ***** ] [03/18/2018 07:44:54] .\inetsrv\iissetup.exe /install SharedLibraries /nano [03/18/2018 07:44:54] Setting Installation Type to Nano [03/18/2018 07:44:55] Successfully added IIS_IUSRS ACE to DACL at %ProgramData%\Microsoft\Windows\WER\ReportQueue. [03/18/2018 07:44:55] Created NetFrameworkConfigurationKey key containter [03/18/2018 07:44:56] Created NetFrameworkConfigurationKey user key [03/18/2018 07:44:56] Set ACLs on NetFrameworkConfigurationKey [03/18/2018 07:44:56] < !!FAIL!! > Failed to create the iisWasKey key container (result=0x8009000f) [03/18/2018 07:44:56] < !!FAIL!! > Install of component SharedLibraries result=0x8009000f [03/18/2018 07:44:56] < !!FAIL!! > COMPONENT::ExecuteCommand result=0x8009000f [03/18/2018 07:44:56] [ End of IIS 10.0 Component Based Setup ]

Глен Литтл
источник
Подобная проблема обсуждалась здесь: stackoverflow.com/questions/47998508/…
Глен Литтл
Еще один аналогичный отчет: answers.microsoft.com/en-us/windows/forum/…
Глен Литтл
И еще один отчет: social.msdn.microsoft.com/Forums/vstudio/en-US/…
Глен Литтл
Другой: serverfault.com/questions/644833/… Ни на один из них нет удовлетворительного ответа.
Глен Литтл

Ответы:

9

Ошибка произошла, потому что WAS не смог получить доступ к ключам машины во время запуска. При первом запуске после обновления WAS попытается создать новые ключи машины, если их нет, или запросит ключи старой машины, оставшиеся от старой ОС. В этом случае существуют старые ключи машин, но, к сожалению, WAS не может получить к ним доступ по неясной причине. Эти машинные ключи используются для шифрования конфиденциальной информации в applicationHost.config или web.config (например, пароль пользователя). WAS не сможет запуститься, если нет ключа машины, который он может использовать.

Следующие шаги по удалению нескольких машинных ключей, используемых IIS, могут помочь запустить WAS - WAS просто заново создаст эти ключи при запуске.

  1. Перейдите в папку ключей компьютера RSA: C: \ Users \ All Users \ Данные приложения \ Microsoft \ Crypto \ RSA \ MachineKeys
  2. Найдите ключ компьютера (файл), имя которого начинается с d6d986f09a1ee04e24c949879fdb506c_ *. Если вы откроете его с помощью блокнота, вы должны увидеть простой текст «NetFrameworkConfigurationKey».
  3. Сделайте резервную копию этого файла в другую папку.
  4. Удалить этот файл
  5. Выполните те же шаги, что и 2-4, для резервного копирования и удаления iisWasKey: 76944fb33636aeddb9590521c2e8815a_ *
  6. Выполните шаги 2-4 для резервного копирования и удаления iisConfigurationKey: 6de9cb26d2b98c01ec4e9e8b34824aa2_ *
  7. Вручную запустить WAS
    • Откройте командную строку через «Запуск от имени администратора».
    • чистый старт был
Янбин Ши
источник
Спасибо, @ yanbing-shi. Пожалуйста, смотрите мои ответы в вопросе.
Глен Литтл
Мы добились определенного прогресса - по крайней мере, NetFrameworkConfigurationKey был успешно создан. Я обновил ответ с дополнительными шагами.
Янбинг Ши
Рад, что обходной путь разблокирует вас. Но коренная причина еще не ясна. Определенно что-то, связанное с ключами машины, было испорчено во время обновления (и IIS не контролирует это). Старые ключи машины были созданы WAS перед обновлением, и обновление Windows переносит эти ключи в новую ОС. Однако совершенно неожиданно, что WAS, работающий под учетной записью SYSTEM, не сможет получить доступ к ключам машины, ранее созданным им самим.
Янбинг Ши
Если вы выполнили мои обходные шаги и сделаете резервную копию трех старых машинных ключей RSA (1) NetFrameworkConfigurationKey (2) iisWasKey (3) iisConfigurationKey. Я был бы признателен, если бы вы предоставили мне следующую информацию: Если вы сравниваете каждый старый ключ (резервную копию) с новым, воссозданным WAS, имеют ли они одинаковое имя файла - например, является ли часть "*" (GUID) одни и те же?
Янбинг Ши
@YanbingShi это решило мою проблему, спасибо. Чтобы ответить на ваш вопрос, новые воссозданные ключи имели то же имя, что и раньше. Мне пришлось изменить разрешения файлов ключей, чтобы переместить их. У меня уже было разрешение, но для удаления мне пришлось специально сделать их доступными, т.
Е. Щелкнуть
4

Для меня это началось после вчерашнего запуска Центра обновления Windows. Установленные обновления с тех пор:

  • Обновление функции до Windows 10, версия 1709
  • Обновление для Windows 10 KB4041994
  • Накопительное обновление 2018-01 KB4056892

Запуск службы активации процессов Windows (WAS) привел к этой ошибке:

Ошибка 13: данные неверны.

Из журнала системных событий:

Службе активации процессов Windows (WAS) не удалось выполнить инициализацию для автономной установки. Поле данных содержит номер ошибки [8007000D].

Понятия не имею, что происходит. Я verfied My administration.config, applicationHost.configи redirection.configсодержал ожидаемые данные.

Я попытался вернуться к автоматическому резервному копированию файлов конфигурации C:\inetpub\history, но безрезультатно.

В конце концов я предпринял следующие шаги:

  1. Сделайте резервную копию всех файлов конфигурации из C:\Windows\System32\inetsrv\Config.

  2. Удалил все HTTP, связанные с этим, сняв флажок в разделе «Функции Windows» (сделайте снимок экрана с установленными, чтобы потом можно было легко переустановить те же модули):

    • В .NET Framework 3.5 не снимайте флажок с самой платформы:
      • WCF HTTP-активация
      • WCF без HTTP-активации
    • .NET Framework 4.7 Расширенные услуги
    • IIS
    • IIS Hostable Web Core
    • Служба активации Windows
  3. Перезагрузка.

  4. Удалил оставшееся содержимое из C:\Windows\System32\inetsrv.
  5. Переустановите все неустановленные функции сверху.
  6. Переустановите модуль перезаписи URL
  7. Осторожно верните соответствующие элементы из-под <applicationPools>и <sites>элементов из резервной копии applicationHost.configво вновь созданный C:\Windows\System32\inetsrv\Config\applicationHost.config.
  8. Выполните iisresetиз командной строки с повышенными правами, просто чтобы быть уверенным.

И ура, все мои сайты по разработке снова.

После этого я сравнил резервные копии и новые applicationHost.configфайлы и не обнаружил каких-либо серьезных отличий. На самом деле, когда я поместил резервную копию applicationHost.configв каталог Config и запустил другую, iisresetвсе по-прежнему работало, так что я думаю, что проблема не в этом файле.

CodeCaster
источник
Я рад, что вы смогли обойти эту проблему. Ранее я делал большую часть этого, но если ничего не появится в ближайшее время, я могу сделать это снова, следуя вашему пути более тщательно. Тем временем я смог переключить свою разработку на использование IIS Express, а не IIS, и сейчас это работает.
Глен Литтл
******** НЕ СОБЛЮДАЙТЕ ЭТОГО СОВЕТА ********. ОЧЕНЬ ОЧЕНЬ ПЛОХО. Поставь мне день в работе. ДЕЙСТВИТЕЛЬНО ПЛОХАЯ КОНСУЛЬТАЦИЯ. После удаления .NET 3.5 вы не сможете переустановить его без особой работы. Я просто рад, что нашел следующий пост, чтобы исправить то, что произошло, следуя приведенным выше инструкциям. damirscorner.com/blog/posts/...
Fractal
1

Это случилось и со мной после недавнего обновления Windows. Выключение и последующее включение службы активации процессов Windows в Windows Features. Выключение этой службы также отключит следующие функции, которые вы также включите:

  • Активация Windows Communication Foundation без HTTP
  • Активация TCP
  • Активация именованных каналов
  • Активация очереди сообщений (MSMQ)
Майк Деланж
источник
1
Отключение WPAS (API конфигурации и модель процесса были включены), а затем их включение не помогли в этом случае.
Глен Литтл
1

Не могли бы вы сделать следующие проверки

  1. Проверьте, есть ли у вас этот раздел реестра: HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ WAS \ Parameters \ NanoSetup

Я считаю, что он должен существовать, если вы столкнулись с такой неудачей запуска WAS.

  1. Проверьте, есть ли у вас файл с именем applicationhost.config.tmp в C: \ windows \ system32 \ inetsrv \ config (папка, в которой находится ваш applicationHost.config).

Этот временный файл должен существовать, чтобы ударить такой сбой.

  1. Откройте iis.log в c: \ windows, прокрутите вниз до конца файла и найдите самые последние ошибки в журнале. Мы ценим, если вы можете вставить сюда любое сообщение об ошибке.

Теперь я подозреваю, что вы увидите ошибки в iis.log. Не могли бы вы вставить здесь ошибки, чтобы сузить причину?

Янбин Ши
источник
1-Да. 2-Да. Добавлены записи в журнале к вопросу выше.
Глен Литтл
Это может быть интересно: forums.iis.net/p/1148509/1865753.aspx
Глен Литтл