문제 해결

Question 1

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 사용량이 거의 2초마다 50%까지 급증하는 경우가 종종 있다는 것을 알았습니다. 이로 인해 배터리 수명이 소모되고 노트북이 뜨거워졌습니다. Sathya가 경험한 것과 거의 동일한 증상입니다. Windows 7의 리소스 모니터를 보는 것만으로도 프로세스 WmiPrvSE.exe에 문제가 있음을 알 수 있었습니다 .

CPU 놈 놈

빠른 구글 검색을 통해 이것이Windows 관리 계측(WMI) 호스트 프로세스. 즉, WMI는 프로세서 사용량, 실행 중인 프로세스, 로그온한 사람 및 기타 모든 종류의 정보와 같은 시스템 정보를 쿼리하는 데 사용할 수 있습니다. WMI 호스트 프로세스는 WMI 쿼리를 생성하는 다른 프로세스에 대해 WMI 쿼리를 실행하므로 WmiPrvSE.exe그 자체가 원인은 아니고 단순히 중개자일 뿐입니다.

어떤 특정 프로세스가 이 문제를 일으키는지 찾아내기 위해 저는 다음을 사용했습니다.Systinternals 프로세스 탐색기. 어떤 WmiPrvSE.exe프로세스의 인스턴스가 CPU를 많이 사용하고 있는지 찾아내고 클릭하면 자세한 정보가 열리게 됩니다.

프로세스 탐색기

불행하게도 어떤 프로세스가 모든 쿼리를 만들고 있는지 알아낼 수 있는 방법이 없었지만, 이를 CPU 급증의 원인으로 분리했고 그것이 서비스라는 것을 알았기 때문에 서비스 관리자에게 가서 어느 프로세스가 실행되는지 확인했습니다. 서비스는 WMI에 의존했기 때문에 또 다른 단서를 찾을 수 있을 것이라고 생각했습니다.

서비스 nom nom

문제를 일으키는 것은 기본 제공 Windows 서비스가 아닐 것이라고 생각했기 때문에 해당 서비스를 제거하고 목록을 살펴보고 각 서비스를 비활성화하고 문제가 지속되는지 확인하기로 결정했습니다. 목록 바로 위에는 HP Wireless Assistant 서비스가 있었습니다. 서비스 메뉴로 돌아가서 해당 서비스를 비활성화했습니다. 작업 관리자를 다시 살펴보니 CPU 사용량이 거의 없어진 것을 확인했습니다. HPWA 서비스를 다시 켰습니다. CPU 사용량이 다시 증가했습니다. 이제 나는 이론을 형성하기에 충분한 데이터를 얻었습니다. HPWA 서비스를 제거했는데 다시는 문제가 발생하지 않았습니다.

가설 검증

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

먼저 리소스 모니터에서 HPWA 서비스를 담당하는 프로세스를 격리했습니다. HPWA_Service.exe그리고 HPWA_Main.exe둘이에요. 다음은 두 가지 처리된 실행 시 CPU 사용량을 보여줍니다.

hpwa가 실행 중인 작업 관리자

그런 다음 두 프로세스를 모두 일시 중지했습니다. CPU 사용량이 즉시 감소했습니다. 그래프의 이전 CPU 사용량이 지워진 후 잠시 후의 모습은 다음과 같습니다.

hpwa가 실행되지 않는 작업 관리자

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

작업 관리자가 방금 hpwa를 활성화했습니다
^{HPWA를 활성화할 때 첫 번째 급증}

hpwa 활성화 후 작업 관리자
^{HPWA를 활성화하고 얼마 후}

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

hpwa 비활성화 후 CPU 사용량 감소

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

HPWA가 하는 일은 무선이 켜지거나 꺼질 때 사용자에게 알리고 CPU를 게걸스럽게 먹는 것뿐입니다. 내장된 무선 관리 도구로는 할 수 없는 일이 없으므로 이 소프트웨어가 설치되어 있으면 제거하는 것이 좋습니다.

메모:HPWA를 제거하면 키보드의 무선 스위치가 작동하지 않는다고 보고한 사람이 한 명 이상 있습니다. 내 노트북에서는 HPWA를 제거한 후에도 계속 잘 작동했지만, 작동이 중지되는 경우 언제든지 Windows 내부에서 무선 카드를 비활성화할 수 있습니다. +를 눌러 xWindows 모바일 센터를 연 다음 Turn Wireless Off버튼을 클릭합니다.

윈도우 모빌리티 센터

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

Answer

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 사용량이 거의 2초마다 50%까지 급증하는 경우가 종종 있다는 것을 알았습니다. 이로 인해 배터리 수명이 소모되고 노트북이 뜨거워졌습니다. Sathya가 경험한 것과 거의 동일한 증상입니다. Windows 7의 리소스 모니터를 보는 것만으로도 프로세스 WmiPrvSE.exe에 문제가 있음을 알 수 있었습니다 .

CPU 놈 놈

빠른 구글 검색을 통해 이것이Windows 관리 계측(WMI) 호스트 프로세스. 즉, WMI는 프로세서 사용량, 실행 중인 프로세스, 로그온한 사람 및 기타 모든 종류의 정보와 같은 시스템 정보를 쿼리하는 데 사용할 수 있습니다. WMI 호스트 프로세스는 WMI 쿼리를 생성하는 다른 프로세스에 대해 WMI 쿼리를 실행하므로 WmiPrvSE.exe그 자체가 원인은 아니고 단순히 중개자일 뿐입니다.

어떤 특정 프로세스가 이 문제를 일으키는지 찾아내기 위해 저는 다음을 사용했습니다.Systinternals 프로세스 탐색기. 어떤 WmiPrvSE.exe프로세스의 인스턴스가 CPU를 많이 사용하고 있는지 찾아내고 클릭하면 자세한 정보가 열리게 됩니다.

프로세스 탐색기

불행하게도 어떤 프로세스가 모든 쿼리를 만들고 있는지 알아낼 수 있는 방법이 없었지만, 이를 CPU 급증의 원인으로 분리했고 그것이 서비스라는 것을 알았기 때문에 서비스 관리자에게 가서 어느 프로세스가 실행되는지 확인했습니다. 서비스는 WMI에 의존했기 때문에 또 다른 단서를 찾을 수 있을 것이라고 생각했습니다.

서비스 nom nom

문제를 일으키는 것은 기본 제공 Windows 서비스가 아닐 것이라고 생각했기 때문에 해당 서비스를 제거하고 목록을 살펴보고 각 서비스를 비활성화하고 문제가 지속되는지 확인하기로 결정했습니다. 목록 바로 위에는 HP Wireless Assistant 서비스가 있었습니다. 서비스 메뉴로 돌아가서 해당 서비스를 비활성화했습니다. 작업 관리자를 다시 살펴보니 CPU 사용량이 거의 없어진 것을 확인했습니다. HPWA 서비스를 다시 켰습니다. CPU 사용량이 다시 증가했습니다. 이제 나는 이론을 형성하기에 충분한 데이터를 얻었습니다. HPWA 서비스를 제거했는데 다시는 문제가 발생하지 않았습니다.

가설 검증

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

먼저 리소스 모니터에서 HPWA 서비스를 담당하는 프로세스를 격리했습니다. HPWA_Service.exe그리고 HPWA_Main.exe둘이에요. 다음은 두 가지 처리된 실행 시 CPU 사용량을 보여줍니다.

hpwa가 실행 중인 작업 관리자

그런 다음 두 프로세스를 모두 일시 중지했습니다. CPU 사용량이 즉시 감소했습니다. 그래프의 이전 CPU 사용량이 지워진 후 잠시 후의 모습은 다음과 같습니다.

hpwa가 실행되지 않는 작업 관리자

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

작업 관리자가 방금 hpwa를 활성화했습니다
^{HPWA를 활성화할 때 첫 번째 급증}

hpwa 활성화 후 작업 관리자
^{HPWA를 활성화하고 얼마 후}

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

hpwa 비활성화 후 CPU 사용량 감소

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

HPWA가 하는 일은 무선이 켜지거나 꺼질 때 사용자에게 알리고 CPU를 게걸스럽게 먹는 것뿐입니다. 내장된 무선 관리 도구로는 할 수 없는 일이 없으므로 이 소프트웨어가 설치되어 있으면 제거하는 것이 좋습니다.

메모:HPWA를 제거하면 키보드의 무선 스위치가 작동하지 않는다고 보고한 사람이 한 명 이상 있습니다. 내 노트북에서는 HPWA를 제거한 후에도 계속 잘 작동했지만, 작동이 중지되는 경우 언제든지 Windows 내부에서 무선 카드를 비활성화할 수 있습니다. +를 눌러 xWindows 모바일 센터를 연 다음 Turn Wireless Off버튼을 클릭합니다.

윈도우 모빌리티 센터

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

Question 2

문제 해결

다운로드ProcDump마이크로소프트 시스인터널스에서.
WmiPrvSE.EXE가 1초 동안 25%에 도달하면 덤프를 수행합니다.
```
procdump.exe -c 25 -s 1 -x WmiPrvSE.EXE %HOMEPATH%\WmiPrvSE.dmp
```
그러면 사용자 폴더에 덤프가 생성됩니다.

이 작업을 1~2회 더 반복하여 더 많은 덤프를 확보하고 원인이 덤프되었으며 또 다른 일반적인 이벤트가 아니라는 것을 확신할 수 있습니다.
덤프 분석온라인선택적으로 공유할 수 있습니다.SpeedyShare.

대안:WinDBG명령과 함께 사용할 수 있습니다 !analyze -v.기호 설정.
표시되는 스택 추적에는 이를 발생시키는 절차가 포함되어야 합니다.

아마도 스택의 상위 절차 중 몇 가지를 Google에서 검색하여 해당 절차가 수행하는 작업에 대한 더 나은 아이디어를 얻을 수 있습니다.
도움이 되지 않으면 더 고급 분석이 필요할 수 있습니다. 다음 섹션을 참조하세요.

다음에서 설정을 다운로드하세요.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 파일을 공유하세요.SpeedyShare.
여기에서 링크를 공유하면 문제의 원인을 찾아서 보여 드리겠습니다.

WmiPrvSE.EXE는 CAPI 저장소에 대해 WMI 쿼리를 실행하기 위한 호스트이므로 XPerf를 사용해도 원인을 찾지 못할 수 있습니다.IPC, 방금 찾은 또 다른 해결책은 설명된 대로 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 상태 정보 활성화, 당신이 사용할 수있는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 모니터:

API Monitor를 다운로드, 설치 및 시작합니다. _{(두 배64비트인 경우: x86 한 번, x64 한 번)}
이동파일-->관리자로 실행
설정API 캡처 필터모듈 에 Rpcrt4.dll.
중단점과 마찬가지로 누가 함수를 호출하는지 알고 싶습니다 RpcServerUseProtSeq.
각각 걸이실행중인 프로세스PID가 낮은 경우는 제외됩니다(충돌 방지를 위해). 이상적으로는 후크 를
걸거나 낮추는 것을 원하지 않습니다 . 단일 프로세스를 시도하고 나중에 연결을 해제할 수도 있습니다.dwm.exewinlogon.exe
후크된 프로세스창문...

하지만... 나는 그것을 시도했고 어떤 과정에 대해서도 감을 잡을 수 있었습니다.
모든 일이 잘 진행된다면,후크된 프로세스RPC 호출에 스레드가 포함되도록 만드는 것입니다.
그리고 이 스레드를 클릭하면 여러 호출이 표시됩니다.
그렇다면 문제를 일으키는 프로세스를 찾은 것입니다!

해결책

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

Answer

문제 해결

다운로드ProcDump마이크로소프트 시스인터널스에서.
WmiPrvSE.EXE가 1초 동안 25%에 도달하면 덤프를 수행합니다.
```
procdump.exe -c 25 -s 1 -x WmiPrvSE.EXE %HOMEPATH%\WmiPrvSE.dmp
```
그러면 사용자 폴더에 덤프가 생성됩니다.

이 작업을 1~2회 더 반복하여 더 많은 덤프를 확보하고 원인이 덤프되었으며 또 다른 일반적인 이벤트가 아니라는 것을 확신할 수 있습니다.
덤프 분석온라인선택적으로 공유할 수 있습니다.SpeedyShare.

대안:WinDBG명령과 함께 사용할 수 있습니다 !analyze -v.기호 설정.
표시되는 스택 추적에는 이를 발생시키는 절차가 포함되어야 합니다.

아마도 스택의 상위 절차 중 몇 가지를 Google에서 검색하여 해당 절차가 수행하는 작업에 대한 더 나은 아이디어를 얻을 수 있습니다.
도움이 되지 않으면 더 고급 분석이 필요할 수 있습니다. 다음 섹션을 참조하세요.

다음에서 설정을 다운로드하세요.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 파일을 공유하세요.SpeedyShare.
여기에서 링크를 공유하면 문제의 원인을 찾아서 보여 드리겠습니다.

WmiPrvSE.EXE는 CAPI 저장소에 대해 WMI 쿼리를 실행하기 위한 호스트이므로 XPerf를 사용해도 원인을 찾지 못할 수 있습니다.IPC, 방금 찾은 또 다른 해결책은 설명된 대로 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 상태 정보 활성화, 당신이 사용할 수있는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 모니터:

API Monitor를 다운로드, 설치 및 시작합니다. _{(두 배64비트인 경우: x86 한 번, x64 한 번)}
이동파일-->관리자로 실행
설정API 캡처 필터모듈 에 Rpcrt4.dll.
중단점과 마찬가지로 누가 함수를 호출하는지 알고 싶습니다 RpcServerUseProtSeq.
각각 걸이실행중인 프로세스PID가 낮은 경우는 제외됩니다(충돌 방지를 위해). 이상적으로는 후크 를
걸거나 낮추는 것을 원하지 않습니다 . 단일 프로세스를 시도하고 나중에 연결을 해제할 수도 있습니다.dwm.exewinlogon.exe
후크된 프로세스창문...

하지만... 나는 그것을 시도했고 어떤 과정에 대해서도 감을 잡을 수 있었습니다.
모든 일이 잘 진행된다면,후크된 프로세스RPC 호출에 스레드가 포함되도록 만드는 것입니다.
그리고 이 스레드를 클릭하면 여러 호출이 표시됩니다.
그렇다면 문제를 일으키는 프로세스를 찾은 것입니다!

해결책

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

Question 3

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

이 방법은 "분석 및 디버그 로그 표시"의 이벤트 뷰어 옵션을 사용하여 모든 WMI 활동을 추적함으로써 문제가 있는 프로세스의 프로세스 ID를 가져옵니다.

Answer

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

이 방법은 "분석 및 디버그 로그 표시"의 이벤트 뷰어 옵션을 사용하여 모든 WMI 활동을 추적함으로써 문제가 있는 프로세스의 프로세스 ID를 가져옵니다.

Question 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

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

이제 다음으로 필터링하세요.Microsoft-Windows-WMI-활동이벤트만 보고 WMI 작업과 ClientProcessId를 찾습니다.

내 예에서는 이 CLIentProcessId가 다음 도구에 속합니다.Veeam ONE 모니터 서버.중지하고 CPU 사용량 문제를 해결했습니다..

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

여기에서는 Intel ProSet 모니터링 서비스에 속하는 PID가 1924인 프로세스의 반복 호출이 표시됩니다.

여기서 CPU 사용량은 CPU 샘플링 호출 스택에도 표시됩니다.

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

Answer

디버깅하려면 다음에서 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

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

이제 다음으로 필터링하세요.Microsoft-Windows-WMI-활동이벤트만 보고 WMI 작업과 ClientProcessId를 찾습니다.

내 예에서는 이 CLIentProcessId가 다음 도구에 속합니다.Veeam ONE 모니터 서버.중지하고 CPU 사용량 문제를 해결했습니다..

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

여기에서는 Intel ProSet 모니터링 서비스에 속하는 PID가 1924인 프로세스의 반복 호출이 표시됩니다.

여기서 CPU 사용량은 CPU 샘플링 호출 스택에도 표시됩니다.

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

문제 해결

답변1

실험 개요

배경 정보

가설 검증

답변2

문제 해결

해결책

답변3

답변4

관련 정보