Я, як правило, тримаю свій ноутбук 24x7, і наприкінці дня справді прикро, щоб мої стегна згоріли через перегрівання.

Здається, перегрівання є результатом того, що Host Provider Host (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% ЦП, коли процес HPWA призупинено.
  3. Подивіться, чи знову процесор починає шипіти, коли процес HPWA знову включений
  4. Повторіть кроки 2 та 3 для декількох випробувань, щоб забезпечити точність результатів
      

• Результати : HPWA викликає надзвичайне використання процесора

• Висновок : Вам слід видалити HPWA, оскільки це не робить нічого корисного

Довідкова інформація

Коли я придбав ноутбук HP Pavillion dm4t, я помітив, що процесор часто сприймає до 50% використання майже кожну другу секунду. Це виснажувало час роботи акумулятора та нагрівало ноутбук; майже такі ж симптоми, як і Сатья. Тільки переглянувши Монітор ресурсів у 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 для використання кнопки включення / вимкнення wifi, ви можете завантажити останню версію з веб-сайту драйверів HP, і, ймовірно, більше не виникне цієї проблеми. Тим не менш, якщо вам не потрібна кнопка включення / вимкнення Wi-Fi, все ж, здається, немає додаткової вартості від встановлення цього програмного забезпечення.

Вирішення проблем

1. Завантажте ProcDump від Microsoft Sysinternals.

2. Нехай це сприймається, коли WmiPrvSE.EXE за 1 секунду потрапить на 25%:

   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. Поділіться стислим поштовим файлом на SpeedyShare .
10. Поділіться посиланням тут, я спробую знайти та показати вам причину вашої проблеми.

Оскільки 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 , ви можете використовувати 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або опустити.
   Ви також можете спробувати окремі процеси та зніміть їх пізніше з вікна Hooked Process ...

   Хоча ... Я спробував це і міг підключити будь-який процес.

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 здається досить приємною для усунення несправностей!