故障排除

Question 1

正如 Sathya 在他的問題中提到的，我以前在類似的 HP 筆記型電腦上遇到過這個問題，現在我用科學方法確認 HP 筆記型電腦上的 CPU 峰值是由 HP Wireless Assistant 引起的。或者，HP CPU 刺客，我可能會開始這樣稱呼它。

實驗概述

問題:是什麼導致 HP 筆記型電腦的 CPU 頻繁出現峰值，特別是 WmiPrvSE.exe 過程？
假設:HP Wireless Assistant (HPWA) 導致了這個問題
方法:
1. 查看安裝 HPWA 後是否開始出現問題。
2. WmiPrvSE.exe當 HPWA 進程暫停時，請查看 CPU 是否停止尖峰並且進程是否停止使用 >20% 的 CPU。
3. 重新啟用 HPWA 進程後，請查看 CPU 是否再次開始尖峰
4. 重複步驟2和3進行多次試驗，以確保結果準確
結果:HPWA 導致 CPU 使用率極高
結論:您應該卸載 HPWA，因為它沒有任何用處

背景資料

當我拿到 HP Pavillion dm4t 筆記型電腦時，我注意到 CPU 的使用率幾乎每隔一秒就會頻繁飆升至 50%。這會耗盡電池壽命，並使筆記型電腦發熱；與沙迪亞經歷過的症狀非常相似。只要查看 Windows 7 中的資源監視器，我就能發現該進程WmiPrvSE.exe有問題。

cpu 標稱標稱

快速的谷歌搜尋證實了我的假設，這就是Windows 管理工具(WMI) 主機進程。簡而言之，WMI 可用於查詢系統訊息，例如處理器使用情況、正在運行的進程、登入者以及各種其他資訊。 WMI 主機進程為任何其他進程執行 WMI 查詢，因此WmiPrvSE.exe它本身並不是罪魁禍首，它只是一個中介。

為了找出導致此問題的特定進程，我使用了Systinternals 流程瀏覽器。我找到了哪個進程實例WmiPrvSE.exe使用了大量CPU，然後單擊它以打開詳細資訊。

流程瀏覽器

不幸的是，我無法找到任何方法來找出哪個進程正在發出所有查詢，但由於我已將其作為CPU 峰值的來源進行隔離，並且知道它是一項服務，因此我前往服務管理器查看哪個進程服務依賴 WMI，我認為這可能會引導我找到另一個線索。

服務名稱

我認為這不會是導致問題的內建 Windows 服務，因此為了消除這些問題，我決定按照清單進行操作並嘗試停用每個服務，看看問題是否仍然存在。位於清單頂部的是惠普無線助理服務。我返回到服務選單，並停用該服務。回頭查看任務管理器，我發現 CPU 使用率幾乎為零。我恢復了 HPWA 服務。 CPU 使用率回升。我現在有足夠的數據來形成我的理論。我卸載了 HPWA 服務，再也沒有出現過這個問題。

驗證假設

幾個月後，沙迪亞問了這個問題。我決定一勞永逸地證明這是 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 內部停用無線網卡。按+x開啟 Windows 行動中心，然後按一下Turn Wireless Off按鈕。

Windows 行動中心

根據討論在 HP 支援論壇上，該問題已在最新版本的 HP Wireless Assistant 中解決。如果您的筆記型電腦需要 HPWA 才能使用 wifi 開/關按鈕，您可以從 HP 驅動程式網站下載最新版本，可能不會再出現此問題。儘管如此，如果您不需要 WiFi 開/關按鈕，安裝此軟體似乎仍然沒有任何附加價值。

Answer

正如 Sathya 在他的問題中提到的，我以前在類似的 HP 筆記型電腦上遇到過這個問題，現在我用科學方法確認 HP 筆記型電腦上的 CPU 峰值是由 HP Wireless Assistant 引起的。或者，HP CPU 刺客，我可能會開始這樣稱呼它。

實驗概述

問題:是什麼導致 HP 筆記型電腦的 CPU 頻繁出現峰值，特別是 WmiPrvSE.exe 過程？
假設:HP Wireless Assistant (HPWA) 導致了這個問題
方法:
1. 查看安裝 HPWA 後是否開始出現問題。
2. WmiPrvSE.exe當 HPWA 進程暫停時，請查看 CPU 是否停止尖峰並且進程是否停止使用 >20% 的 CPU。
3. 重新啟用 HPWA 進程後，請查看 CPU 是否再次開始尖峰
4. 重複步驟2和3進行多次試驗，以確保結果準確
結果:HPWA 導致 CPU 使用率極高
結論:您應該卸載 HPWA，因為它沒有任何用處

背景資料

當我拿到 HP Pavillion dm4t 筆記型電腦時，我注意到 CPU 的使用率幾乎每隔一秒就會頻繁飆升至 50%。這會耗盡電池壽命，並使筆記型電腦發熱；與沙迪亞經歷過的症狀非常相似。只要查看 Windows 7 中的資源監視器，我就能發現該進程WmiPrvSE.exe有問題。

cpu 標稱標稱

快速的谷歌搜尋證實了我的假設，這就是Windows 管理工具(WMI) 主機進程。簡而言之，WMI 可用於查詢系統訊息，例如處理器使用情況、正在運行的進程、登入者以及各種其他資訊。 WMI 主機進程為任何其他進程執行 WMI 查詢，因此WmiPrvSE.exe它本身並不是罪魁禍首，它只是一個中介。

為了找出導致此問題的特定進程，我使用了Systinternals 流程瀏覽器。我找到了哪個進程實例WmiPrvSE.exe使用了大量CPU，然後單擊它以打開詳細資訊。

流程瀏覽器

不幸的是，我無法找到任何方法來找出哪個進程正在發出所有查詢，但由於我已將其作為CPU 峰值的來源進行隔離，並且知道它是一項服務，因此我前往服務管理器查看哪個進程服務依賴 WMI，我認為這可能會引導我找到另一個線索。

服務名稱

我認為這不會是導致問題的內建 Windows 服務，因此為了消除這些問題，我決定按照清單進行操作並嘗試停用每個服務，看看問題是否仍然存在。位於清單頂部的是惠普無線助理服務。我返回到服務選單，並停用該服務。回頭查看任務管理器，我發現 CPU 使用率幾乎為零。我恢復了 HPWA 服務。 CPU 使用率回升。我現在有足夠的數據來形成我的理論。我卸載了 HPWA 服務，再也沒有出現過這個問題。

驗證假設

幾個月後，沙迪亞問了這個問題。我決定一勞永逸地證明這是 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 內部停用無線網卡。按+x開啟 Windows 行動中心，然後按一下Turn Wireless Off按鈕。

Windows 行動中心

根據討論在 HP 支援論壇上，該問題已在最新版本的 HP Wireless Assistant 中解決。如果您的筆記型電腦需要 HPWA 才能使用 wifi 開/關按鈕，您可以從 HP 驅動程式網站下載最新版本，可能不會再出現此問題。儘管如此，如果您不需要 WiFi 開/關按鈕，安裝此軟體似乎仍然沒有任何附加價值。

Question 2

故障排除

下載過程轉儲來自微軟 Sysinternals。
一旦 WmiPrvSE.EXE 達到 25% 持續 1 秒，就讓它進行轉儲：
```
procdump.exe -c 25 -s 1 -x WmiPrvSE.EXE %HOMEPATH%\WmiPrvSE.dmp
```
這將在您的用戶資料夾中建立一個轉儲。

請隨意重複此操作 1 - 2 次，以便您有更多轉儲，並且可以確定原因已被轉儲，而不是另一個更正常的事件。
分析您的轉儲在線的並可選擇分享極速分享。

選擇: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 文件極速分享。
在這裡分享鏈接，我將嘗試找到並向您展示問題的原因。

由於 WmiPrvSE.EXE 是針對 CAPI 儲存體執行 WMI 查詢的主機，因此即使使用 XPerf，您也可能無法找到原因，因為工控機，我剛剛發現的另一個解決方案是啟用 WMI 日誌記錄並按所述檢查日誌這裡，ClientProcessId 將是進行 WMI 查詢的進程的 PID。透過將 PID 欄位新增至工作管理員或流程瀏覽器，或tasklist /FI "PID eq X"其中 X 是您找到的 PID...

分析轉儲1:第 94-115 行表示遠程過程調用。
分析轉儲2:第 84-105 行表示遠程過程調用。

在核心中，啟動一個新線程處理遠端過程呼叫存根，本質上是 WMI 提供者將執行並回應的查詢請求。由於讀取註冊表和/或效能信息，這會導致 CPU 活動較高。

由於轉儲是對單一時刻的捕獲，因此您將無法看到哪個進程執行了 RPC。
因此，您需要一個像 XPerf 一樣進行追蹤的程式來查看執行 RPC 的前一個執行緒。

或者，如果你啟用 RPC 狀態訊息，您可以使用遠端控制資料庫查看是誰發起的呼叫。

例子：

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.exe/winlogon.exe或放下。
您也可以嘗試單一進程並稍後從掛鉤進程窗戶...

雖然......我已經嘗試過並且可以掛鉤任何過程。
如果一切順利的話，鉤式工藝這使得 RPC 呼叫將包含線程。
單擊這些線程後，您應該會看到一堆呼叫。
如果這樣做，您就找到了導致問題的進程！

解決方案

讓您的電腦保持最新狀態很重要，安裝HPWA 4.0.10.0解決這個問題！;-)

Answer

故障排除

下載過程轉儲來自微軟 Sysinternals。
一旦 WmiPrvSE.EXE 達到 25% 持續 1 秒，就讓它進行轉儲：
```
procdump.exe -c 25 -s 1 -x WmiPrvSE.EXE %HOMEPATH%\WmiPrvSE.dmp
```
這將在您的用戶資料夾中建立一個轉儲。

請隨意重複此操作 1 - 2 次，以便您有更多轉儲，並且可以確定原因已被轉儲，而不是另一個更正常的事件。
分析您的轉儲在線的並可選擇分享極速分享。

選擇: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 文件極速分享。
在這裡分享鏈接，我將嘗試找到並向您展示問題的原因。

由於 WmiPrvSE.EXE 是針對 CAPI 儲存體執行 WMI 查詢的主機，因此即使使用 XPerf，您也可能無法找到原因，因為工控機，我剛剛發現的另一個解決方案是啟用 WMI 日誌記錄並按所述檢查日誌這裡，ClientProcessId 將是進行 WMI 查詢的進程的 PID。透過將 PID 欄位新增至工作管理員或流程瀏覽器，或tasklist /FI "PID eq X"其中 X 是您找到的 PID...

分析轉儲1:第 94-115 行表示遠程過程調用。
分析轉儲2:第 84-105 行表示遠程過程調用。

在核心中，啟動一個新線程處理遠端過程呼叫存根，本質上是 WMI 提供者將執行並回應的查詢請求。由於讀取註冊表和/或效能信息，這會導致 CPU 活動較高。

由於轉儲是對單一時刻的捕獲，因此您將無法看到哪個進程執行了 RPC。
因此，您需要一個像 XPerf 一樣進行追蹤的程式來查看執行 RPC 的前一個執行緒。

或者，如果你啟用 RPC 狀態訊息，您可以使用遠端控制資料庫查看是誰發起的呼叫。

例子：

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.exe/winlogon.exe或放下。
您也可以嘗試單一進程並稍後從掛鉤進程窗戶...

雖然......我已經嘗試過並且可以掛鉤任何過程。
如果一切順利的話，鉤式工藝這使得 RPC 呼叫將包含線程。
單擊這些線程後，您應該會看到一堆呼叫。
如果這樣做，您就找到了導致問題的進程！

解決方案

讓您的電腦保持最新狀態很重要，安裝HPWA 4.0.10.0解決這個問題！;-)

Question 3

微軟部落格條目WMIprvse 是真正的惡棍嗎？顯示如何尋找哪個程序負責 WmiPrvSE.exe 正在使用的 CPU。

此方法使用事件檢視器的「顯示分析和偵錯日誌」選項來追蹤所有 WMI 活動，從而取得有罪程序的進程 ID。

Answer

微軟部落格條目WMIprvse 是真正的惡棍嗎？顯示如何尋找哪個程序負責 WmiPrvSE.exe 正在使用的 CPU。

此方法使用事件檢視器的「顯示分析和偵錯日誌」選項來追蹤所有 WMI 活動，從而取得有罪程序的進程 ID。

Question 4

要調試它，請使用 xperfWindows 效能工具包並運行這個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，並將「Generic Events」圖表從左側拖曳到分析窗格中。

現在過濾到Microsoft-Windows-WMI-活動僅事件，並尋找 WMI 操作和 ClientProcessId。

在我的範例中，此 CLientProcessId 屬於一個名為的工具Veeam ONE 監控伺服器。停止它，解決了CPU使用問題。

第二個範例如下圖所示：

您可以在此處看到 PID 為 1924 的進程的重複調用，該進程屬於英特爾 ProSet 監控服務。

這裡 CPU 使用率也顯示在 CPU 採樣呼叫堆疊：

因此，Intel 工具過於頻繁地執行 WMI 通知查詢，這導致了問題。停止它，解決了問題。

Answer

要調試它，請使用 xperfWindows 效能工具包並運行這個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，並將「Generic Events」圖表從左側拖曳到分析窗格中。

現在過濾到Microsoft-Windows-WMI-活動僅事件，並尋找 WMI 操作和 ClientProcessId。

在我的範例中，此 CLientProcessId 屬於一個名為的工具Veeam ONE 監控伺服器。停止它，解決了CPU使用問題。

第二個範例如下圖所示：

您可以在此處看到 PID 為 1924 的進程的重複調用，該進程屬於英特爾 ProSet 監控服務。

這裡 CPU 使用率也顯示在 CPU 採樣呼叫堆疊：

因此，Intel 工具過於頻繁地執行 WMI 通知查詢，這導致了問題。停止它，解決了問題。

故障排除

答案1

實驗概述

背景資料

驗證假設

答案2

故障排除

解決方案

答案3

答案4

相關內容