Дело об ошибке сервиса Windows Installer

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

clip_image002[4]

Сообщение об ошибке из этого диалога переводится следующим образом: «Нельзя получить доступ к сервису Windows Installer. Это может быть из-за неверной установки Windows Installer. Для помощи свяжитесь с обслуживающим персоналом.»

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

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

clip_image004

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

clip_image006

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

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

clip_image008clip_image010

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

clip_image012

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

clip_image014

Действительно, кликнув правой клавишей мыши на пути и выбрав «Перейти к…» (jump to) из контекстного меню Process Monitor он убедился, что не только параметр ObjectName пропущен в разделе реестра Msiserver проблемной системы, но и весь раздел пуст. На рабочей системе он был заполнен параметрами, требующимися для настройки сервиса Windows:

clip_image016

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

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

Другие советы по использованию Process Monitor, а также дополнительные иллюстрации к случаям поиска неисправностей можно найти в книге «Windows Sysinternals Administrator’s Reference», которую я недавно опубликовал совместно с Аароном Марголисом. Если вы прочли ее, пожалуйста, оставьте ее обзор на Amazon.com.