2011-02-02 12:36:08 +0000 2011-02-02 12:36:08 +0000
88
88

Почему WMI Provider Host (WmiPrvSE.exe) постоянно увеличивает нагрузку на процессор?

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

Перегрев, похоже, является результатом того, что WMI Provider Host (WmiPrvSE.exe) увеличивает нагрузку на процессор до 25% каждые несколько минут. Почему это происходит?

У меня есть HP Envy 14 (с включенным в комплект поставки дерьмом HP), работающий под Windows 7 Home Premium.

(Примечание: Основываясь на @nhinkle’s прошлые наблюдения , кажется, что HP Wireless Manager может быть виновен, есть ли способ подтвердить это? )

Этот вопрос был * Вопрос суперпользователя недели . Прочитайте 28 февраля 2011 года * запись в блоге для получения более подробной информации или * отправьте свой собственный ** Вопрос недели.

Ответы (6)

110
110
110
2011-02-05 23:05:12 +0000

Как Сатья упомянул в своем вопросе, у меня был предыдущий опыт решения этой проблемы на моем аналогичном ноутбуке HP, и теперь, используя научный метод, я подтвердил, что скачки процессора на ноутбуках HP вызваны беспроводным помощником HP Wireless Assistant. Или, HP CPU Assassin, как я могу начать называть его.

Обзор Эксперимент

  • Question : Что вызывает скачок процессора на ноутбуках HP с частыми интервалами, а именно WmiPrvSE.exe процесс?

  • Гипотеза : Беспроводной помощник HP (HPWA) вызывает проблему

  • Метод :

  • Результы : HPWA вызывает экстремальное использование процессора

  • Включение : Вы должны удалить HPWA, так как он не делает ничего полезного

Фоновая информация

Когда я получил свой ноутбук HP Pavillion dm4t, я заметил, что процессор часто увеличивается до 50% использования, почти каждую секунду. Это истощало время работы батареи и разогревало ноутбук; те же самые симптомы, что и у Сатья. Просто взглянув на Resource Monitor в Windows 7, я смог увидеть, что процесс WmiPrvSE.exe был неисправен.

Быстрый поиск в Google подтвердил мое предположение, что это был процесс хоста Windows Management Instrumentation (WMI). Короче говоря, WMI можно использовать для запроса системной информации, такой как использование процессора, запущенные процессы, кто вошел в систему, и различной другой информации. Процесс хоста WMI выполняет WMI-запросы для любого другого процесса, делающего их, поэтому WmiPrvSE.exe сам по себе не является виновником, а просто посредником.

Для того, чтобы выяснить, какой именно процесс вызывал эту проблему, я использовал Systinternals Process Explorer . Я обнаружил, какой экземпляр процесса WmiPrvSE.exe использует большое количество CPU, и нажал на него, чтобы открыть подробную информацию.

К сожалению, я не смог найти способа выяснить, какой процесс делает все запросы, но поскольку я изолировал это как источник всплесков процессора, и знал, что это сервис, я пошел к менеджеру служб, чтобы посмотреть, какие сервисы зависят от WMI, думая, что это может привести меня к другой подсказке.

я подумал, что это не встроенная служба Windows, вызывающая проблему, поэтому, устранив ее, я решил работать по списку и попробовал отключить каждую службу, и посмотреть, сохранилась ли проблема. Прямо наверху списка была служба HP Wireless Assistant Service. Я вернулся в меню служб и отключил эту службу. Оглядываясь назад в диспетчере задач, я увидел, что использование процессора практически ничего не изменилось. Я снова включил службу HPWA. Снимок использования процессора. Теперь у меня было достаточно данных, чтобы сформировать свою теорию. Я удалил службу HPWA, и у меня больше никогда не было проблем.

Проверка гипотезы

Несколько месяцев спустя, Сатья задает этот вопрос. Я решил доказать раз и навсегда, что это была вина HPWA. Я переустановил HP Wireless Assistant, который не устанавливался несколько месяцев. Прямо сейчас, использование процессора увеличилось. Затем я прошел эксперимент, описанный выше.

Сначала я изолировал процесс, отвечающий за службу HPWA, в Мониторе ресурсов. HPWA_Service.exe и HPWA_Main.exe - это два процесса. Вот как выглядело использование процессора, когда оба процесса работали:

Затем я приостановил оба процесса. Использование процессора сразу же снизилось; вот как это выглядело через несколько секунд после предыдущего использования процессора на графике, чтобы очистить:

Я снова включил процессы, чтобы посмотреть, будет ли использование восстанавливаться. Получилось:

Первый всплеск при включении HPWA

Немного спустя некоторое время после включения HPWA

Приостановка процессов снова привела к снижению использования процессора:

Я протестировал это для еще одной итерации, а в третьем триале то же самое повторилось снова. Я посчитал это достаточным доказательством того, что проблема была вызвана беспроводным помощником HP Wireless Assistant, а затем отключил службу, и теперь удалил ее.

Все, что HPWA, похоже, делает, это информирует пользователя о том, когда его беспроводная сеть включена или выключена, и пожирает процессор. Нет ничего, что можно было бы сделать со встроенными средствами управления беспроводной связью, поэтому я бы посоветовал, если у вас установлено это программное обеспечение, удалить его.

  • *

Заметка: По крайней мере, один человек сообщил, что удаление HPWA привело к тому, что их беспроводной переключатель на клавиатуре перестал работать. На моем ноутбуке он продолжал нормально работать после удаления HPWA, но в случае, если ваш ноутбук перестанет работать, вы всегда можете отключить беспроводную карту изнутри Windows. Нажмите

+x, чтобы открыть Центр мобильности Windows, затем нажмите кнопку Turn Wireless Off.

  • *

Согласно обсуждение на форумах поддержки HP, проблема была исправлена в более поздних версиях HP Wireless Assistant. Если ваш ноутбук нуждается в HPWA для использования Wi-Fi вкл/выкл. кнопку, вы можете скачать последнюю версию с сайта драйверов HP, и, вероятно, больше не будет иметь этой проблемы. Тем не менее, если вам не нужна кнопка включения/выключения Wi-Fi, похоже, что установка этого программного обеспечения не принесет никакой пользы.

38
38
38
2011-02-02 13:11:14 +0000

Устранение неполадок

  1. Скачайте ProcDump из Microsoft Sysinternals.

  2. Пусть сделает дамп после того, как WmiPrvSE.EXE в течении 1 секунды будет на 25%:

  3. Проанализируйте ваш дамп(ы) online и, опционально, поделитесь им на SpeedyShare .

  4. Трасса стека, которая отображается, должна включать в себя процедуру, которая вызывает это.

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

  • *
  1. Загрузите настройку из Windows Performance Analysis Tools для вашей версии Windows.
  2. Установите программное обеспечение на вашу систему.
  3. Откройте командную строку в качестве администратора и скопируйте следующую команду:

  4. Нажмите ENTER once, чтобы запустить команду, теперь вам придется подождать, пока не произойдет всплеск.

  5. Прямо после шипа вы идете на консоль и нажимаете ENTER.

  6. После некоторого времени ожидания в вашей пользовательской папке будет создан лог-файл myTrace.etl.

  7. Выполните следующую команду, чтобы показать файл и проанализировать его WinDBG Symbols required):

Если вы хотите, чтобы я взглянул на него:

  1. Сожмите myTrace.etl из вашей Пользовательской папки в zip-файл.
  2. Поделитесь сжатым zip файлом на SpeedyShare .
  3. Поделитесь ссылкой здесь, я попытаюсь найти и показать вам причину вашей проблемы.
  • *

Как WmiPrvSE. EXE является хостом для выполнения WMI запросов против хранилища CAPI, вы не сможете найти причину даже в XPerf из-за IPC , еще одним решением, которое я только что нашел, будет включение записи логов WMI и проверка логов, как описано здесь , ClientProcessId будет PID процесса, который сделал WMI запрос. Этот PID может быть отслежен обратно в процесс путем добавления столбца PID в диспетчер задач или Обозреватель процесса , или с помощью tasklist /FI "PID eq X", где X - это PID, который вы нашли…

  • *

Анализ Дампа 1 : Строки 94-115 указывают на Вызов удаленной процедуры .
Анализ Дамп 2 : Линии 84-105 указывают на Вызов удаленной процедуры .

В ядре запускается новый поток для работы с ветвью вызова удаленной процедуры , который, по сути, является запросом, на который WMI-провайдер выполнит и ответит. Это приводит к высокой активности процессора из-за чтения информации о реестре и/или производительности.

Поскольку дамп - это захват одного момента, вы не сможете увидеть, какой процесс выполнял RPC. Поэтому вам нужна программа, которая отслеживает, как XPerf, чтобы увидеть предыдущий поток, который будет выполнять RPC.

Или, если вы включите RPC State Information , вы можете использовать rpcdbg , чтобы увидеть, кто инициировал вызов.

Пример:

0:000> bp rpcrt4!RpcServerUseProtseqEpA
0:000> g
Breakpoint 0 hit
eax=00452000 ebx=7ffd5000 ecx=00452008 edx=00000014 esi=00d5f55c edi=7c911970
eip=77e97a0b esp=0012ff3c ebp=0012ff6c iopl=0 nv up ei pl nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000206
RPCRT4!RpcServerUseProtseqEpA:
77e97a0b 8bff mov edi,edi
0:000> kb
ChildEBP RetAddr Args to Child
0012ff38 00401046 00452000 00000014 00452008 RPCRT4!RpcServerUseProtseqEpA
0012ff6c 00401e37 00000001 003330a0 00333120 hellos!main+0x46 [e:\projects\hello\hellos.c @ 21]

Вышеприведенный пример устанавливает точку останова на RPC, так что вы сможете увидеть, кто запустил его во второй строке стека. Но вряд ли установка точки останова при первом вызове (обратите внимание, что это живая отладка) поможет вам увидеть, кто каждый раз вызывает WMI Provider…

В этой статье гораздо больше информации о RPC State Information , которая может помочь, но не для таких слабонервных, как мы, чтобы пройти через все это, когда мы могли бы просто использовать XPerf вместо этого. :-)

  • *

Как мы теперь знаем о внутренней работе RPC, мы могли бы также использовать API Monitor :

  1. Скачать, установить и запустить API Monitor. ( twice если у вас 64-битный: раз x86, раз x64)
  2. Перейдите к Файлу –> Запустите от имени администратора
  3. Установите API-фильтр захвата в модуль Rpcrt4.dll.

  4. Аналогично точке останова, мы хотим знать, кто вызывает функции RpcServerUseProtSeq:

  5. Перехватить каждый Запущенный процесс, за исключением тех, с низким PID (для предотвращения сбоев). Идеально, вы не хотите перехватить dwm.exe/winlogon.exe или ниже. Вы также можете попробовать отдельные процессы и отсоединить их позже из окна Запущенные процессы

  6. Если все пойдет хорошо, Hooked Process, который делает вызов RPC будет содержать потоки. И при нажатии на эти потоки, вы должны увидеть кучу вызовов. Если вы это сделаете, вы нашли процесс, вызывающий проблему!

Решение

Поддержание вашего компьютера в актуальном состоянии важно, установка HPWA 4.0.10.0 решает эту проблему! ;-)

13
13
13
2011-02-06 19:14:14 +0000

Запись в блоге Microsoft Является ли WMIprvse настоящим злодеем? _ показывает, как найти процесс, отвечающий за процессор, который использует WmiPrvSE.exe.

Метод использует опцию Event viewer “Show Analytic and Debug Logs”, чтобы отследить всю активность WMI, тем самым получая процессуальное удостоверение виновного процесса.

7
7
7
2014-11-14 08:17:34 +0000

Просто добавив это для всех остальных в той же лодке, эта страница по всему Google. У меня была та же проблема с WmiProvderHost шипованных процессоров до 50% и разрядки батареи на моем Lenovo Yoga2 Pro на Windows 8.1.

После некоторых из отличных советов исследования выше, я обнаружил проблему для меня было на самом деле GoPro Studio (бесплатное программное обеспечение для редактирования видео, которое поставляется с камерами GoPro). Он устанавливает службу мониторинга, которая ждет вас, чтобы подключить камеру, и для меня это был преступник.

4
4
4
2015-08-02 16:07:23 +0000

Для отладки используйте xperf из Windows Performance Toolkit и запустите этот cmd файл:

xperf -on PROC_THREAD+LOADER+PROFILE+INTERRUPT+DPC+DISPATCHER -stackwalk profile -BufferSize 1024 -MaxFile 256 -FileMode Circular -f Kernel.etl
xperf -start WMILogger -on Microsoft-Windows-WMI-Activity::0xff -BufferSize 1024 -f WMI.etl

echo Please capture about 30s of the WMI activity.

pause

xperf -stop
xperf -stop WMILogger
xperf -merge WMI.etl kernel.etl WMItracing.etl

del WMI.etl
del kernel.etl

Open the generated WMItracing.etl in WPA.exe и grag & drop the “Generic Events” graph from the left side to the analysis pane.

Теперь отфильтровать только события Microsoft-Windows-WMI-Activity, и искать операции WMI и ClientProcessId.

В моем примере это CLientProcessId принадлежит инструменту под названием Veeam ONE Monitor Server. Остановка, исправление проблемы использования процессора .

И второй пример показан здесь:

HEre you see re repeat repeating calls of a Process with PID of 1924, который принадлежит службе Intel ProSet Monitoring.

Здесь использование процессора также показано в сэмплировании вызовов:

Таким образом, утилита Intel слишком часто выполняет запросы WMI-уведомлений, что приводит к возникновению проблем. Остановка, исправление проблемы.

1
1
1
2011-02-02 13:36:08 +0000

Ты пробовал проверить, не вирус ли это? Некоторые вирусы очень любят выставлять напоказ такие службы Windows. Убедитесь, что процесс WmiPrvSE.exe расположен в каталоге c:\windows\system32\wbem. Если нет, то, возможно, вы захотите запустить общие программы обнаружения шпионского ПО. Если это не шпионское ПО, возможно, это другая служба, которая его вызывает. Я знаю, что на моем компьютере быстро работает несколько гаджетов, и, по иронии судьбы, гаджет монитора производительности иногда заставляет мой процессор немного ускоряться. Кроме того, это может быть еще одна служба, которая время от времени давит на этот газ. Например, bloatware от HP, Dell и т.д.

Кроме того, другой ответ от TomWij кажется довольно хорошим для устранения неполадок!

Похожие вопросы

3
10
28
13
6