Дело об ошибке службы установки

Этот случай произошел с системным администратором, которому было поручено развернуть клиентское программное обеспечение Windows Intune в своей сети. Windows Intune - это облачный сервис, который управляет системами в корпоративной сети, устанавливая на программное обеспечение доступные обновления и позволяя администраторам следить за здоровьем этих систем через веб-интерфейс. Для его работы требуется клиентская программа, однако на одной из систем она не смогла установиться, выдав следующее сообщение об ошибке:

Данное сообщение можно перевести как "Служба установки Windows не доступна. Это могло произойти из-за того, что установщик Windows установлен неправильно. Свяжитесь с вашей службой поддержки".

Администратор, посмотрев одну из моих презентаций из серии "Дело о необъяснимом", в которой я советовал "если сомневаешься - запускай Process Monitor", скачал копию этой утилиты с сайта Sysinternals.com и получил трассировку активности системы во время неудачной установки. Он последовал стандартной технике диагностики проблем, заключающейся в просмотре списка операций с конца в поисках операции, которая могла бы послужить причиной проблемы, однако после часа поисков он сдался и пошел иным путем. Вместо поисков подсказок в данной трассировке, он решил, что сможет найти причину проблемы, сравнивая трассировку активности системы, на которой появилась ошибка, с трассировкой системы, на которой установка прошла успешно.

Спустя несколько минут у него было две трассировки для сравнения. Он установил фильтр, включив только события, связанные с Msiexec.exe - программой установки клиента, и продолжил просматривать список событий с проблемной системы, сравнивая их с соответствующими событиями с рабочей системы. В конечном счете, он дошел до пункта, в котором две трассировки расходились. В обоих случаях есть ссылка на HKLM\System\CurrentControlSet\Services\BFE, но у проблемной трассировки после нее есть запрос ключа реестра ComputerName:

Трассировка активности рабочей системы, с другой стороны, продолжается операциями с новым экземпляром Msiexec.exe, что он заметил благодаря изменившемуся идентификатору процесса Msiexec.exe, которым сопровождались последующие операции:

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

Он сразу заметил, что в трассировке работающей системы было много событий от процесса Svchost.exe, которых не было в трассировке с проблемной системы. Предположив, что активность процесса Svchost.exe не связана с проблемой, он добавил фильтр для исключения соответствующих записей. Теперь события в обоих трассировках от процесса Services.exe опять совпадали:

Однако, это было не надолго. Спустя десяток операций в трассировке проблемной системы появилась ссылка на HKLM\System\CurrentControlSet\Services\Msiserver\ObjectName с ошибкой NAME NOT FOUND:

В трассировке с работающей системы была такая же операция, однако там она завершилась успешно:

Разумеется, щелчок правой кнопкой мыши по этому событию и вызов команды "Jump to" из контекстного меню Process Monitor подтвердил, что не только значение ObjectName отсутствовало в ключе Msiserver в проблемной системе, но и весь этот ключ в целом был пуст. На работающей системе он содержал значения реестра, необходимые для настройки сервиса Windows:

По какой-то причине регистрация службы для сервиса MSI была нарушена, на что и указывало первоначальное окно об ошибке, в котором, однако, не было подсказки о том, как можно решить эту проблему. И то, почему эта служба была повреждена, вероятно, навсегда останется тайной, однако теперь важно то, как это исправить. Для этого он просто использовал функцию экспорта в Regedit для сохранения содержимого ключей работающей системы в файл .reg и затем импортировал их в проблемную систему. После этого он повторно запустил установщик Windows Intune и все прошло без каких-либо ошибок.

С помощью Process Monitor и определенной доли усердия, он затратил около 45 минут на решение проблемы, которая могла бы привести к потере им нескольких часов своего времени на повторную установку системы и восстановление всех приложений и настроек.

Вы можете найти дополнительную информацию об использовании Process Monitor, а также описание решения других проблем с ее помощью в книге Windows Sysinternals Administrator’s Reference, которую я опубликовал вместе с Аароном Маргозисом (Aaron Margosis). Если вы прочитали ее, пожалуйста, оставьте свой отзыва на Amazon.com.


Источник: http://blogs.technet.com/markrussinovich
Перевод: Dazila