В настоящее время я управляю системой Citrix-farm на базе Windows Server 2008R2. Раньше я использовал сценарий Powershell для проверки запущенных пользовательских процессов и перезапуска их при необходимости.
Я использовал инструмент «tasklist.exe» с дополнительными параметрами, чтобы проверить, выполняется ли определенный процесс от имени вошедшего в систему пользователя. К сожалению, tasklist.exe перестал работать в течение нескольких дней. При перезапуске появляется сообщение об ошибке:
«Ошибка: не найдено» или «Ошибка: недопустимый класс».
Поскольку серверы находятся в Германии, я перевел сообщение с немецкого на английский. На немецком сервере это называется
«Fehler: Nicht gefunden» и «Fehler: Ungultige Klasse».
Итак, я не уверен, что перевод на английский правильный. В журнале событий нет журналов ошибок.
Поскольку это производственная система, не было никаких изменений, таких как обновления, и нет подключения к Интернету.
Возможно ли, что отсутствует регистрация dll? Я проверил с помощью «depends.exe» все, что могло бы быть неправильным, но я не могу определить разницу между рабочим и нерабочим серверами.
Я также проверил, нет ли ошибок при запуске «dcomcnfg», но все в порядке.
Свежая копия tasklist.exe с рабочего сервера не заработала. Проблема не связана с самим исполняемым файлом.
Подсказка под эта ссылка был проверен с отрицательным результатом.
regsvr32% Windir% \ system32 \ wbem \ fastprox.dll
regsvr32% Windir% \ system32 \ wbem \ wbemprox.dll
regsvr32% Windir% \ system32 \ wbem \ wbemsvc.dll
Шаблоны вирусов обновлены (McAfee VDS 8.8 + ASE 8.8).
Есть ли у кого-нибудь предложения по поводу того, как снова запустить «tasklist.exe»? В качестве альтернативы мне нужно решение с командами Powershell, которые помогли бы восстановить функции «tasklist.exe» - это непростая задача, поскольку я не лучший скриптер.
Заранее благодарим вас за помощь, подсказки или предложения!
Редактировать:
На самом деле проблема была связана с WMI. Совет от Райана Райса проверить WMI с помощью
«Wbemtest»
привел к аналогичной ошибке при попытке подключения.
В этом случае я получил код ошибки, с помощью которого я смог найти решение на Microsoft TechNet.
Сценарий, указанный на этой странице, у меня не работал, но команда
«Winmgmt / salvagerepository»
сделал.
Так что спасибо, Райан, за подсказку WMI и спасибо r.tanner.f за обходной путь на случай, если все остальное не сработало.
Хотя для получения списка запущенных в системе процессов можно использовать что-то еще, помимо tasklist.exe, меня беспокоит, что tasklist.exe внезапно перестал работать. Это базовый, фундаментальный процесс в системе, и тот факт, что он перестал работать, может быть признаком повреждения данных или другой проблемы, которая может только усугубиться.
Не пытаться выяснить, что вызвало это, даже если вы можете обойти это с помощью Powershell, WMIC или какого-либо другого исполняемого файла, все равно что прикрывать индикатор «Check Oil» на приборной панели вашего автомобиля изолентой. Это не значит, что основной проблемы все еще нет.
Кроме того, похоже, что tasklist.exe использует WMI для получения информации, поэтому, если tasklist.exe не работает, это может указывать на системную проблему с WMI на вашем компьютере, и поэтому использование других инструментов, которые полагаются на WMI, вероятно, не будет работать либо ...
Вот как вы это устраняете. Получите Process Monitor от Sysinternals. Захватывайте события на рабочей машине и фиксируйте события на неработающей машине. Отфильтруйте tasklist.exe при его запуске. Теперь поместите два файла трассировки рядом и посмотрите, чем они отличаются. Какие события на рабочей машине возвращают УСПЕХ, когда те же события на неработающей машине возвращают ИМЯ НЕ НАЙДЕНО или какой-либо другой код неудачи?
Поскольку в сообщении об ошибке вы упомянули недопустимый класс, я уверен, что события, происходящие в разделах реестра HKCR\CLSID\{GUID}\, \HKLM\Software\Classesи т. д., покажут определенные различия между двумя файлами трассировки.
Изменить: также, если вы хотите протестировать сам WMI, один из методов, который вы можете использовать, - запустить wbemtest. Нажмите Connect..., и используйте root\cimv2 как пространство имен. Вы должны иметь возможность оставить все остальное пустым или по умолчанию. Затем нажмите кнопку с надписью Query, и введите select * from win32_process как ваш запрос и нажмите Apply. Вы должны вернуть кучу действительных дескрипторов процесса и никаких сообщений об ошибках.
Удачи...
Вероятно, будет проще заменить использование tasklist.exe небольшим PowerShell, чем отслеживать, что пошло не так, как tasklist.exe. Однако посмотрите на ответ Райана Райса; он делает несколько хороших выводов о том, почему важно отслеживать это, и что WMI может быть сломан и помешать этому работать в любом случае (в этом случае у вас есть более серьезные проблемы). Как бы то ни было, мне больше нравится его ответ.
Проверить процесс, запущенный текущим пользователем, в PowerShell достаточно просто:
Get-WMIObject win32_process |
Where {$_.ProcessName -eq "foo.exe"} |
ForEach-Object {$_.GetOwner()} |
Where {$_.User -eq [Environment]::Username}
Get-WMIObject очевидно, получает объект WMI, в данном случае win32_process. Подключите это к Where-Object и отфильтруйте все, что не равно foo.exe. Затем переберите каждый объект и запустите GetOwner() метод. Наконец, отфильтруйте любое имя пользователя, не равное текущему пользователю.
Я добавляю возврат после каналов для удобочитаемости (также действителен в сценарии), но вы также можете сократить его с помощью некоторых псевдонимов и придерживаться одной строки:
gwmi win32_process | ?{$_.ProcessName -eq "smartclient.exe"} | %{$_.GetOwner()} | ?{$_.User -eq [Environment]::UserName}
PowerShell дружелюбен и не кусается. Вам не нужно быть хорошим сценаристом, чтобы получить от него то, что вам нужно, поэтому не уклоняйтесь от попыток его использовать.