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

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

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

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

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

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

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

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

• Гипотеза : HP Wireless Assistant (HPWA) вызывает проблему

• Метод :

  1. Посмотрите, начинает ли проблема возникать при установке HPWA.
  2. Посмотрите, перестанет ли процессор работать, и WmiPrvSE.exeпроцесс перестанет использовать> 20% CPU, когда процесс HPWA будет приостановлен.
  3. Посмотрите, не начинает ли процессор снова пикировать при повторном включении процесса HPWA
  4. Повторите шаги 2 и 3 для нескольких испытаний, чтобы обеспечить точность результатов
      

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

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

Исходная информация

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

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

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

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

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

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

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

Сначала я выделил процесс, отвечающий за службу HPWA, в Resource Monitor. 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, кажется, что установка этого программного обеспечения не принесет никакой пользы.

Поиск неисправностей

1. Загрузите ProcDump от Microsoft Sysinternals.

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

   procdump.exe -c 25 -s 1 -x WmiPrvSE.EXE %HOMEPATH%\WmiPrvSE.dmp
   

   Это создаст дамп в вашей папке пользователя.

   Не стесняйтесь повторять это еще 1-2 раза, чтобы у вас было больше дампов, и вы можете быть уверены, что причина сброшена, а не другое более нормальное событие.

3. Анализируйте свои дампы онлайн и, при желании, делитесь ими на SpeedyShare .

   Альтернатива : WinDBG может использоваться с командой !analyze -v, обязательно установите символы .

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

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

1. Загрузите установку из средств анализа производительности Windows для вашей версии Windows.
2. Установите программное обеспечение в вашей системе.

3. Откройте командную строку от имени администратора и скопируйте и вставьте следующую команду:

   xperf -start perf!GeneralProfiles.InBuffer -stackwalk profile && timeout -1 && xperf -stop perf!GeneralProfiles.InBuffer %HOMEPATH%\myTrace.etl
   

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

5. Сразу после шипа вы идете к консоли и нажимаете ENTER.
6. Через некоторое время в вашей пользовательской папке появится файл журнала myTrace.etl.

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

   xperf %HOMEPATH%\myTrace.etl
   

Если вы хотите, чтобы я посмотрел на это:

8. Сожмите myTrace.etl из вашей пользовательской папки в ZIP-файл.
9. Поделитесь сжатым zip-файлом на SpeedyShare .
10. Поделитесь ссылкой здесь, я сделаю попытку найти и показать вам причину вашей проблемы.

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

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

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

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

Или, если вы включите информацию о состоянии RPC , вы можете использовать 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 каждый раз ...

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

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

1. Скачайте, установите и запустите API Monitor. _{( дважды, если у вас 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 решает эту проблему! ;-)

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

Метод использует опцию просмотра событий «Показать аналитические и отладочные журналы» для отслеживания всей активности WMI, получая, таким образом, идентификатор процесса виновного процесса.

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

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

Чтобы отладить его, используйте xperf из набора средств Windows Performance и запустите этот 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

Откройте созданный файл WMItracing.etl в WPA.exe и перетащите график «Общие события» с левой стороны на панель анализа.

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

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

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

ЗДЕСЬ вы видите повторяющиеся вызовы процесса с PID 1924, который принадлежит службе мониторинга Intel ProSet.

Здесь использование ЦП также показано в стеках выборки ЦП:

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

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

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