Обычно я держу свой ноутбук включенным 24 часа в сутки, 7 дней в неделю, и в конце дня меня очень раздражает, когда из-за перегрева у меня обгорают бедра.
Перегрев, похоже, является результатом того, что WMI Provider Host (WmiPrvSE.exe) увеличивает загрузку ЦП до 25% каждые несколько минут. Почему это происходит?
У меня HP Envy 14 (с установленной HP-программой) на Windows 7 Home Premium.
(Примечание: основано на @nhinkleпрошлые наблюдения(Похоже, что причиной может быть HP Wireless Manager. Есть ли способ это подтвердить?)
Этот вопрос былВопрос недели для суперпользователей.
Прочитать 28 февраля 2011 г.запись в блогедля получения более подробной информации илиотправьте свой собственныйВопрос недели.
решение1
Как упомянул Сатья в своем вопросе, у меня уже был опыт с этой проблемой на моем похожем ноутбуке HP, и теперь я подтвердил, используя научный метод, что скачки ЦП на ноутбуках HP вызваны HP Wireless Assistant. Или HP CPU Assassin, как я могу его называть.
Обзор эксперимента
Вопрос:Что заставляет процессор на ноутбуке HP часто перезагружаться, в частности
WmiPrvSE.exeпроцесс?Гипотеза:HP Wireless Assistant (HPWA) вызывает проблему
Метод:
- Посмотрите, начнет ли возникать проблема после установки HPWA.
- Проверьте, прекратится ли пиковая загрузка ЦП и
WmiPrvSE.exeперестанет ли процесс использовать более 20% ЦП при приостановке процесса HPWA. - Проверьте, начнет ли снова резко загружаться ЦП при повторном включении процесса HPWA.
- Повторите шаги 2 и 3 для нескольких испытаний, чтобы обеспечить точность результатов.
Полученные результаты:HPWA вызывает чрезмерную загрузку ЦП
Заключение:Вам следует удалить HPWA, так как он не приносит никакой пользы.
Исходная информация
Когда я получил свой ноутбук HP Pavillion dm4t, я заметил, что процессор часто подскакивал до 50% загрузки, почти каждую секунду. Это разряжало аккумулятор и нагревало ноутбук; во многом те же симптомы, что и у Сатьи. Просто взглянув на монитор ресурсов в Windows 7, я смог увидеть, что процесс WmiPrvSE.exeбыл неисправен.
Быстрый поиск в Google подтвердил мое предположение, что этоИнструментарий управления Windows(WMI) хост-процесс. Короче говоря, WMI может использоваться для запроса системной информации, такой как использование процессора, запущенные процессы, кто вошел в систему и всякую другую информацию. Хост-процесс WMI запускает запросы WMI для любого другого процесса, который их делает, поэтому WmiPrvSE.exeсам по себе не является виновником, он был просто посредником.
Чтобы выяснить, какой именно процесс вызывал эту проблему, я использовалОбозреватель процессов SystinternalsЯ нашел, какой экземпляр процесса 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, то, похоже, установка этого ПО все равно не дает дополнительных преимуществ.
решение2
Поиск неисправностей
СкачатьПрокДампот Microsoft Sysinternals.
Дайте ему сделать сброс, как только WmiPrvSE.EXE достигнет 25% в течение 1 секунды:
procdump.exe -c 25 -s 1 -x WmiPrvSE.EXE %HOMEPATH%\WmiPrvSE.dmpЭто создаст дамп в вашей папке пользователя.
Можете смело повторить это еще 1–2 раза, чтобы у вас было больше сбросов и вы могли быть уверены, что причина устранена, а не другое более обычное событие.
Проанализируйте свой дамп(ы)В сетии по желанию поделиться им наSpeedyПоделиться.
Альтернатива:WinDBGможно использовать с командой
!analyze -v, обязательнонабор символов.Показанная трассировка стека должна включать процедуру, вызывающую эту ошибку.
Возможно, погуглите несколько из лучших процедур стека, чтобы лучше понять, что они делают.
Если они не помогут, вам может понадобиться более продвинутый анализ. Смотрите мой следующий раздел:
- Загрузите установку с сайтаИнструменты анализа производительности Windowsдля вашей версии Windows.
- Установите программное обеспечение на свою систему.
Откройте командную строку.как администратори скопируйте и вставьте следующую команду:
xperf -start perf!GeneralProfiles.InBuffer -stackwalk profile && timeout -1 && xperf -stop perf!GeneralProfiles.InBuffer %HOMEPATH%\myTrace.etlНажиматьENTER один разчтобы запустить команду, теперь вам придется дождаться, пока произойдет скачок.
- Сразу после вашего скачкаВы идете к консоли и нажимаете ENTER.
- Через некоторое время в вашей пользовательской папке будет создан файл журнала myTrace.etl.
Выполните следующую команду, чтобы отобразить файл и проанализировать его (WinDBG/Символынеобходимый):
xperf %HOMEPATH%\myTrace.etl
Если вы хотите, чтобы я рассмотрел этот вопрос:
- Сожмите myTrace.etl из папки пользователя в zip-файл.
- Поделитесь сжатым zip-файлом наSpeedyПоделиться.
- Поделитесь ссылкой здесь, я попытаюсь найти и показать вам причину вашей проблемы.
Поскольку WmiPrvSE.EXE является хостом для выполнения запросов WMI к хранилищу CAPI, вы можете не иметь возможности найти причину даже с помощью XPerf из-заМПК, еще одно решение, которое я только что нашел, — включить ведение журнала WMI и проверять журналы, как описаноздесь, ClientProcessId будет PID процесса, который сделал запрос WMI. Этот PID можно отследить до процесса, добавив столбец PID в диспетчер задач илиИсследователь процессов, или 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 Provider каждый раз...
В этой статье гораздо больше информации оИнформация о состоянии RPCэто может помочь, но не для таких слабонервных, как мы, проходить через все это, когда мы могли бы просто использовать XPerf. :-)
Поскольку мы теперь знаем о внутреннем устройстве RPC, мы могли бы также использоватьAPI-монитор:
- Загрузите, установите и запустите API Monitor. (дваждыесли у вас 64 бит: один раз x86, один раз x64)
- Идти кФайл-->Запустить от имени администратора
УстановитьФильтр захвата APIк
Rpcrt4.dllмодулю.
Подобно точке останова, мы хотим знать, кто вызывает функции
RpcServerUseProtSeq:
Крючок каждыйВыполнение процессаза исключением тех, у кого низкий PID (чтобы предотвратить сбои).
В идеале, вы не хотите зацепитьdwm.exe/winlogon.exeили ниже.
Вы также можете попробовать отдельные процессы и отцепить их позже отЗацепленные процессыокно...Хотя... я пробовал и могу зацепить любой процесс.
Если все пройдет хорошо, тоЗацепленный процессчто делает вызов RPC будет содержать потоки.
И при нажатии на эти потоки вы должны увидеть кучу вызовов.
Если вы это сделаете, вы нашли процесс, вызывающий проблему!
Решение
Важно поддерживать компьютер в актуальном состоянии, устанавливаяHPWA 4.0.10.0решает эту проблему!;-)
решение3
Запись в блоге MicrosoftWMIprvse — настоящий злодей?показано, как определить, какой процесс отвечает за использование ЦП процессом WmiPrvSE.exe.
Метод использует опцию средства просмотра событий «Показать аналитические и отладочные журналы» для отслеживания всей активности WMI, тем самым получая идентификатор процесса, вызвавшего ошибку.
решение4
Для отладки используйте xperf изНабор инструментов для оценки производительности Windowsи запустите этот 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.Остановив его, устранил проблему с загрузкой ЦП..
А второй пример показан здесь:
ЗДЕСЬ вы видите повторяющиеся вызовы процесса с PID 1924, который принадлежит службе мониторинга Intel ProSet.
Здесь также показано использование ЦП в стеках вызовов выборки ЦП:
Таким образом, инструмент Intel слишком часто отправляет запросы уведомлений WMI, и это вызывает проблемы.Остановив его, проблема была устранена.