故障排除

Question 1

正如 Sathya 在他的问题中提到的，我之前在类似的 HP 笔记本电脑上也遇到过这个问题，现在我使用科学方法确认 HP 笔记本电脑上的 CPU 峰值是由 HP Wireless Assistant 引起的。或者，我可能会称之为 HP CPU Assassin。

实验概述

问题：是什么导致 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%。这会耗尽电池寿命，并使笔记本电脑发热；与 Sathya 遇到的症状非常相似。只需查看 Windows 7 中的资源监视器，我就能发现该过程WmiPrvSE.exe存在问题。

CPU 额定值

通过谷歌搜索，我证实了我的假设，这就是Windows 管理规范(WMI) 主机进程。简而言之，WMI 可用于查询系统信息，如处理器使用情况、正在运行的进程、登录用户以及各种其他信息。WMI 主机进程会为发出查询的任何其他进程运行 WMI 查询，因此它WmiPrvSE.exe本身并不是罪魁祸首，它只是一个中介。

为了找出导致此问题的具体过程，我使用了Systinternals 进程浏览器。我发现哪个进程实例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 使用情况：

正在运行 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 Assassin。

实验概述

问题：是什么导致 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%。这会耗尽电池寿命，并使笔记本电脑发热；与 Sathya 遇到的症状非常相似。只需查看 Windows 7 中的资源监视器，我就能发现该过程WmiPrvSE.exe存在问题。

CPU 额定值

通过谷歌搜索，我证实了我的假设，这就是Windows 管理规范(WMI) 主机进程。简而言之，WMI 可用于查询系统信息，如处理器使用情况、正在运行的进程、登录用户以及各种其他信息。WMI 主机进程会为发出查询的任何其他进程运行 WMI 查询，因此它WmiPrvSE.exe本身并不是罪魁祸首，它只是一个中介。

为了找出导致此问题的具体过程，我使用了Systinternals 进程浏览器。我发现哪个进程实例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 使用情况：

正在运行 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

故障排除

下载进程转储来自 Microsoft Sysinternals。
一旦 WmiPrvSE.EXE 达到 25% 并持续 1 秒，就让它转储一次：
```
procdump.exe -c 25 -s 1 -x WmiPrvSE.EXE %HOMEPATH%\WmiPrvSE.dmp
```
这将在您的用户文件夹中创建一个转储。

请随意重复此操作 1 - 2 次，以便您获得更多转储，并可以确定原因是转储而不是另一个更正常的事件。
分析你的转储在线的并可选择分享到快速分享。

选择：数据库管理软件可以与命令一起使用!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。
运行以下命令来显示文件并对其进行分析（数据库管理软件/符号必需的）：
```
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 状态信息，您可以使用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.exe/winlogon.exe或更低的进程。
您也可以尝试单个进程，然后稍后将它们从挂钩进程窗户...

虽然...我已经尝试过了并且可以钩住任何进程。
如果一切顺利的话，钩子进程进行 RPC 调用的进程将包含线程。
单击这些线程后，您应该会看到一堆调用。
如果看到，则表明您已找到导致问题的进程！

解决方案

保持计算机更新非常重要，安装HPWA 4.0.10.0解决了这个问题！;-)

Answer

故障排除

下载进程转储来自 Microsoft Sysinternals。
一旦 WmiPrvSE.EXE 达到 25% 并持续 1 秒，就让它转储一次：
```
procdump.exe -c 25 -s 1 -x WmiPrvSE.EXE %HOMEPATH%\WmiPrvSE.dmp
```
这将在您的用户文件夹中创建一个转储。

请随意重复此操作 1 - 2 次，以便您获得更多转储，并可以确定原因是转储而不是另一个更正常的事件。
分析你的转储在线的并可选择分享到快速分享。

选择：数据库管理软件可以与命令一起使用!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。
运行以下命令来显示文件并对其进行分析（数据库管理软件/符号必需的）：
```
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 状态信息，您可以使用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.exe/winlogon.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

要调试它，请使用 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，然后将“通用事件”图表从左侧拖放到分析窗格。

现在过滤Microsoft-Windows-WMI-活动事件，并查找 WMI 操作和 ClientProcessId。

在我的示例中，此 CLientProcessId 属于一个名为的工具Veeam ONE 监控服务器。停止它，修复了 CPU 使用率问题。

第二个例子如下所示：

在这里您可以看到对 PID 为 1924 的进程的重复调用，该进程属于 Intel ProSet 监控服务。

这里 CPU 使用率也显示在 CPU 采样调用堆栈中：

因此，英特尔工具过于频繁地执行 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，然后将“通用事件”图表从左侧拖放到分析窗格。

现在过滤Microsoft-Windows-WMI-活动事件，并查找 WMI 操作和 ClientProcessId。

在我的示例中，此 CLientProcessId 属于一个名为的工具Veeam ONE 监控服务器。停止它，修复了 CPU 使用率问题。

第二个例子如下所示：

在这里您可以看到对 PID 为 1924 的进程的重复调用，该进程属于 Intel ProSet 监控服务。

这里 CPU 使用率也显示在 CPU 采样调用堆栈中：

因此，英特尔工具过于频繁地执行 WMI 通知查询，从而导致了问题。停止它，问题解决。

故障排除

答案1

实验概述

背景信息

验证假设

答案2

故障排除

解决方案

答案3

答案4

相关内容