나는 일반적으로 내 노트북을 연중 무휴로 유지하며 하루가 끝나면 과열로 허벅지가 화상을 입는 것이 정말 짜증납니다.

과열은 WMI Provider Host (WmiPrvSE.exe)가 몇 분마다 CPU 사용률을 25 %로 급등시킨 결과로 보입니다. 왜 이런 일이 발생합니까?

Windows 7 Home Premium에서 HP Envy 14 (HP 번들 쓰레기 포함)를 실행하고 있습니다.

(참고 : @nhinkle의 과거 관찰 에 따르면 HP Wireless Manager가 범인 일 수 있습니다.이를 확인할 방법이 있습니까?)

이 질문은 금주 의 슈퍼 사용자 질문입니다 . 자세한 내용은
2011 년 2 월 28 일 블로그 항목 을 읽 거나 자신의주의 질문을 제출하십시오 .

Sathya가 그의 질문에서 언급했듯이, 나는 비슷한 HP 랩탑에서이 문제에 대해 이전에 경험 한 적이 있으며, 이제 HP 랩탑의 CPU 스파이크가 HP Wireless Assistant에 의해 발생한다는 과학적인 방법을 사용하여 확인했습니다. 또는 HP CPU Assassin이라고 부를 수 있습니다.

실험 개요

• 질문 : HP 랩탑의 CPU가 빈번한 간격, 특히 프로세스 에서 급증하는 원인은 무엇입니까 WmiPrvSE.exe ?

• 가설 : HPWA (HP Wireless Assistant)가 문제를 일으킴

• 방법 :

  1. HPWA가 설치 될 때 문제가 발생하는지 확인하십시오.
  2. WmiPrvSE.exeHPWA 프로세스가 일시 중단되었을 때 CPU가 스파이크를 중지하고 프로세스가> 20 % CPU를 사용하여 중지하는지 확인하십시오 .
  3. HPWA 프로세스가 다시 활성화 될 때 CPU가 다시 스파이크를 시작하는지 확인
  4. 정확한 결과를 보장하기 위해 여러 번의 시도에 대해 2 단계와 3 단계를 반복하십시오.
      

• 결과 : HPWA가 과도한 CPU 사용을 유발하고 있습니다

• 결론 : HPWA는 아무 소용이 없으므로 제거해야합니다.

배경 정보

HP Pavillion dm4t 랩톱을 구입했을 때 CPU가 거의 1 초마다 사용량이 50 % 나되는 것으로 나타났습니다. 이로 인해 배터리 수명이 줄어들고 랩탑이 가열되었습니다. Sathya가 경험 한 것과 거의 동일한 증상. Windows 7의 리소스 모니터를 보면 프로세스 WmiPrvSE.exe에 결함이 있음을 알 수있었습니다 .

빠른 Google 검색에서 이것이 WMI ( Windows Management Instrumentation ) 호스트 프로세스 라는 가정을 확인했습니다 . 요컨대, WMI를 사용하여 프로세서 사용, 프로세스 실행, 로그온 한 사람 및 기타 모든 종류의 정보와 같은 시스템 정보를 쿼리 할 수 ​​있습니다. WMI 호스트 프로세스는 다른 프로세스를 위해 WMI 쿼리를 실행하므로 WmiPrvSE.exe그 자체로는 범인이 아니기 때문에 단순히 중개자였습니다.

이 문제를 일으키는 특정 프로세스를 찾아 내기 위해 Systinternals Process Explorer를 사용 했습니다 . WmiPrvSE.exe프로세스 의 어떤 인스턴스가 많은 양의 CPU를 사용하고 있는지 확인한 후 클릭하여 자세한 정보를 엽니 다.

불행히도, 어떤 프로세스가 모든 쿼리를 수행하고 있는지 알 수있는 방법을 알 수 없었지만 CPU 스파이크의 소스로 이것을 분리하고 서비스라는 것을 알았으므로 서비스 관리자에게 가서 서비스는 WMI에 의존하여 다른 단서로 이어질 수 있다고 생각했습니다.

나는 그것이 문제를 일으키는 기본 제공 Windows 서비스가 아니라고 생각하여 목록을 제거하고 각 서비스를 비활성화하고 문제가 지속되는지 확인하기로 결정했습니다. 목록 맨 위에는 HP Wireless Assistant 서비스가있었습니다. 서비스 메뉴로 돌아가서 해당 서비스를 비활성화했습니다. 작업 관리자를 되돌아 보면 CPU 사용량이 거의없는 것으로 나타났습니다. HPWA 서비스가 다시 켜졌습니다. CPU 사용량이 백업되었습니다. 나는 이제 내 이론을 형성하기에 충분한 데이터를 가졌다. HPWA 서비스를 제거했지만 다시 문제가 발생하지 않았습니다.

가설 검증

몇 달 후, Sathya는이 질문을합니다. 나는 이것이 HPWA의 잘못이라는 것을 단번에 증명하기로 결정했습니다. 몇 달 동안 설치하지 않은 HP Wireless Assistant를 다시 설치했습니다. 바로 프로세서 사용량이 증가했습니다. 그런 다음 위에서 설명한 실험을 진행했습니다.

먼저, 리소스 모니터에서 HPWA 서비스를 담당하는 프로세스를 분리했습니다. HPWA_Service.exe그리고 HPWA_Main.exe둘입니다. 이 두 가지 처리 된 실행에서 CPU 사용량은 다음과 같습니다.

그런 다음 두 프로세스를 일시 중단했습니다. CPU 사용량이 즉시 감소했습니다. 다음은 그래프에서 이전 CPU 사용량을 확인하기 위해 잠시 후의 모습입니다.

사용량이 다시 발생하는지 확인하기 위해 프로세스를 다시 활성화했습니다. 그게했다:

^{HPWA를 활성화 한 첫 번째 스파이크}

^{HPWA를 활성화 한 후 잠시}

프로세스를 다시 일시 중단하면 CPU 사용량이 다시 감소합니다.

나는 이것을 한 번 더 반복해서 테스트했으며 세 번째 시도에서 똑같은 일이 다시 발생했습니다. HP Wireless Assistant가 문제를 일으킨다는 것을 보여주는이 충분한 증거를 고려한 후 서비스를 비활성화하고 이제 제거 할 것입니다.

모든 HPWA는 무선을 켜거나 끌 때 사용자에게 알리고 CPU를 고치기 만하는 것 같습니다. 내장 무선 관리 도구로는 할 수없는 일이 없으므로이 소프트웨어가 설치되어 있으면 제거하는 것이 좋습니다.

참고 : 한 명 이상이 HPWA를 제거하면 키보드의 무선 스위치가 작동을 멈췄다 고보고했습니다. 랩톱에서 HPWA를 제거한 후에도 계속 작동하지만 작동이 중지되는 경우 Windows 내부에서 항상 무선 카드를 비활성화 할 수 있습니다. + x를 눌러 Windows Mobility Center를 연 다음 Turn Wireless Off버튼 을 클릭하십시오 .

HP 지원 포럼에 대한 토론 에 따르면 최신 버전의 HP Wireless Assistant에서 문제가 해결되었습니다. 랩톱에서 wifi 켜기 / 끄기 버튼을 사용하기 위해 HPWA가 필요한 경우 HP 드라이버 웹 사이트에서 최신 버전을 다운로드 할 수 있으며이 문제는 더 이상 발생하지 않을 수 있습니다. 그럼에도 불구하고 wifi 켜기 / 끄기 버튼에 필요하지 않은 경우에도이 소프트웨어를 설치해도 아무런 부가 가치가없는 것 같습니다.

문제 해결

1. Microsoft Sysinternals에서 ProcDump 를 다운로드 하십시오.

2. WmiPrvSE.EXE가 1 초 동안 25 %에 도달하면 덤프를 수행하십시오.

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

   그러면 User 폴더에 덤프가 생성됩니다.

   이 덤프를 1-2 번 더 반복하여 덤프를 더 많이 확보하고 원인이 덤프되고 다른 일반적인 이벤트가 아닌지 확인할 수 있습니다.

3. 덤프를 온라인으로 분석 하고 선택적으로 SpeedyShare에서 공유하십시오 .

   대안 : WinDBG를 명령과 함께 사용할 수 있으므로 기호!analyze -v 를 설정 해야합니다 .

4. 표시되는 스택 추적에는이를 일으키는 절차가 포함되어야합니다.

아마도 구글이 스택의 최상위 절차 중 일부를 수행하여 더 나은 아이디어를 얻을 수 있습니다.
도움이되지 않으면 고급 분석이 필요할 수 있습니다. 다음 섹션 참조 :

1. Windows 버전에 대한 Windows 성능 분석 도구 에서 설정을 다운로드하십시오 .
2. 시스템에 소프트웨어를 설치하십시오.

3. administrator 로 명령 프롬프트 를 열고 다음 명령을 복사하여 붙여 넣습니다.

   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 / 기호 필요).

   xperf %HOMEPATH%\myTrace.etl
   

내가 조사 해보고 싶다면 :

8. 사용자 폴더에서 zip 파일로 myTrace.etl을 압축하십시오.
9. SpeedyShare 에서 압축 된 zip 파일을 공유하십시오 .
10. 여기 링크를 공유하십시오. 문제의 원인을 찾아서 보여 드리려고합니다.

WmiPrvSE.EXE는 CAPI 저장소에 대해 WMI 쿼리를 실행하기위한 호스트이므로 IPC 로 인해 XPerf에서도 원인을 찾지 못할 수 있습니다. 방금 찾은 또 다른 솔루션은 WMI 로깅을 활성화하고 로그를 확인하는 것입니다 여기 에 설명 된대로 ClientProcessId는 WMI 쿼리를 만든 프로세스의 PID입니다. 이 PID는 작업 관리자 또는 프로세스 탐색기에 PID 열을 추가 하거나 tasklist /FI "PID eq X"X가 찾은 PID 를 사용하여 프로세스로 다시 추적 할 수 있습니다 .

덤프 1 분석 : 라인 94-115는 원격 프로 시저 호출을 나타냅니다 . 덤프 2
분석 : 84-105 행은 원격 프로 시저 호출을 나타냅니다 .

커널에서 원격 프로 시저 호출 스텁을 처리 하기 위해 새 스레드가 시작 되는데 , 이는 본질적으로 WMI 제공자가 실행하고 응답하는 쿼리 요청입니다. 이로 인해 레지스트리 및 / 또는 성능 정보를 읽음으로써 높은 CPU 활동이 발생합니다.

덤프는 단일 시점의 캡처이므로 RPC를 수행 한 프로세스를 볼 수 없습니다.
따라서 RPC를 수행하는 이전 스레드를 보려면 XPerf와 같은 추적 프로그램이 필요합니다.

또는 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 공급자를 호출하는지 확인하는 데 도움이되지 않을 것입니다 ...

이 기사에는 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. 모든 것이 잘되면 RPC 호출을 만드는 후크 프로세스 에 스레드가 포함됩니다.
   이 스레드를 클릭하면 많은 호출이 표시됩니다.
   그렇다면 문제를 일으키는 과정을 찾았습니다!

해결책

컴퓨터를 최신 상태로 유지하는 것이 중요합니다. HPWA 4.0.10.0을 설치 하면 이 문제가 해결됩니다! ;-)

Microsoft 블로그 항목 WMIprvse는 진정한 악당입니까? WmiPrvSE.exe가 사용중인 CPU를 담당하는 프로세스를 찾는 방법을 보여줍니다.

이 방법은 "분석 및 디버그 로그 표시"의 이벤트 뷰어 옵션을 사용하여 모든 WMI 활동을 추적하여 유죄 프로세스의 프로세스 ID를 얻습니다.

같은 보트에있는 다른 사람을 위해 이것을 추가하면이 페이지가 Google에 있습니다. Windows 8.1의 Lenovo Yoga2 Pro에서 WmiProvderHost가 CPU를 최대 50 %까지 높이고 배터리를 소모하는 것과 동일한 문제가있었습니다.

위의 훌륭한 조사 조언에 따라, 실제로 GoPro Studio (GoPro 카메라와 함께 제공되는 무료 비디오 편집 소프트웨어)라는 문제가 발견되었습니다 . 그것은 당신이 당신의 카메라를 연결하기를 기다리는 모니터링 서비스를 설치하고 저에게 이것은 범인이었습니다.

디버깅하려면 Windows 성능 툴킷 에서 xperf를 사용하고이 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

WPA.exe에서 생성 된 WMItracing.etl을 열고 "일반 이벤트"그래프를 왼쪽에서 분석 창으로 가져옵니다.

이제 Microsoft-Windows-WMI-Activity 이벤트 만 필터링하고 WMI 작업 및 ClientProcessId를 찾으십시오.

내 예 에서이 CLientProcessId는 Veeam ONE Monitor Server 라는 도구에 속합니다 . 중지하고 CPU 사용 문제를 해결했습니다 .

두 번째 예는 다음과 같습니다.

인텔 ProSet 모니터링 서비스에 속하는 PID가 1924 인 프로세스의 호출이 반복되는 것을 볼 수 있습니다.

CPU 사용량은 CPU 샘플링 콜 스택에도 표시됩니다.

따라서 인텔 도구는 WMI 알림 쿼리를 너무 자주 수행하므로 문제가 발생합니다. 중지하고 문제를 해결했습니다.

바이러스인지 확인하려고 했습니까? 일부 바이러스는 실제로 Windows 서비스와 같은 퍼레이드를 좋아합니다. WmiPrvSE.exe프로세스가 c:\windows\system32\wbem디렉토리 에 있는지 확인하십시오 . 그렇지 않은 경우 일반적인 스파이웨어 탐지 프로그램을 실행할 수 있습니다. 스파이웨어가 아닌 경우이를 호출하는 다른 서비스 일 수 있습니다. 나는 내 컴퓨터에서 몇 가지 가제트를 빠르게 실행하고 있으며, 아이러니하게도 성능 모니터 가제트는 때때로 CPU 스파이크를 조금만 만듭니다. 또한 매번 그 가스를 누르는 또 다른 서비스가 될 수 있습니다. 예를 들어 HP, Dell 등의 블로 트웨어

그 외에 TomWij의 다른 답변은 문제를 해결하는 데 꽤 좋습니다!