我正在查询WMI（win32_perfrawdata_perfproc_process类）并且发生了一些奇怪的事情：第一次查询时，它会停止将近50秒来显示答案。下一次几乎是立竿见影的。
有人看到这种行为吗？有什么可以避免的吗？
要重现此操作，请打开Powershell窗口并键入
gwmi win32_perfrawdata_perfproc_process
第一次运行此命令时，它会停止将近50秒。第二次几乎是即刻的。
布鲁诺
答案 0 :(得分：0)
六年后回答这个问题为时已晚吗？ ：）
第一次WMI查询（从任何来源，无论是Powershell，wmic命令行，还是通过COM调用以编程方式）的大约20秒的延迟都是正常的。我已将其跟踪到RPC / TCP连接。根据{{3}}：
从Windows Vista开始，服务控制管理器（SCM） 支持两个传输控制上的远程过程调用 协议（RPC / TCP）和命名管道（RPC / NP）。客户端SCM功能 默认情况下使用RPC / TCP。
RPC / TCP适用于大多数使用SCM功能的应用程序 远程，例如远程管理或监视工具。然而， 为了兼容性和性能，某些应用程序可能需要 通过设置此中描述的注册表值来禁用RPC / TCP 主题。
当服务调用远程SCM功能时，客户端SCM首先 尝试使用RPC / TCP与服务器端SCM通信。如果 服务器运行的Windows版本支持RPC / TCP和 如果允许RPC / TCP通信，则RPC / TCPP连接将成功。如果 服务器运行的Windows版本不支持RPC / TCP， 或支持RPC / TCP，但在防火墙允许下运行 仅命名管道流量，RPC / TCP连接超时和SCM 重试与RPC / NP的连接。最终将成功，但是 可能需要一些时间（通常超过20秒），导致 OpenSCManager函数显示为被阻止。
上面的链接指定可以更改以消除此延迟的注册表值。它们在HKLM\SYSTEM\CurrentControlSet\Control下。通过将SCMApiConnectionParam超时值更改为5000，我已经能够将延迟缩短到仅5秒。