简介本资源是微软官方发布的Windows Management InstrumentationWMI英文开发文档PDF合集面向Windows系统开发人员、IT管理员及自动化运维工程师用于深入理解WMI底层架构、编写管理脚本或开发C/C/C#/.NET平台的WMI客户端与提供程序。文档内容体系完整涵盖WMI核心概念与COM关系、提供程序-存储库-客户端三级架构、Win32_OperatingSystem等关键类详解、root\cimv2等命名空间说明以及类SQL语法的WQL查询语言与典型应用示例如进程监控、软件枚举。资源为单文件PDF体积57.3MB内容源自Microsoft官方技术文档站含PowerShell集成说明Get-WmiObject等cmdlet、.NET Framework调用指南及跨版本兼容性提示支持Windows Management Infrastructure。目前已有112人学习下载适合需权威参考、快速查阅类定义、构建远程管理方案或排查WMI服务异常的技术人员。1. WMI 到底是什么一个 Windows 系统的“数字体检报告系统”想象你刚买了一台新电脑想立刻知道它“心脏跳得稳不稳”“内存吃得饱不饱”“硬盘有没有悄悄发烧”——但你没法切开机箱拿听诊器去听。WMI 就是微软在 Windows 里悄悄装好的那套“内置体检系统”它不靠你手动点开任务管理器也不等你打开资源监视器而是24小时持续采集 CPU 温度、进程列表、磁盘读写、服务状态、网络连接、电源策略……所有这些数据都被标准化地组织起来像医院里的电子病历一样随时待命、按需调取。它不是某个具体软件也不是一个你能在开始菜单里找到的图标它是 Windows 底层的一套“管理基础设施”就像水电管道埋在墙里——你看不见但热水器一开就有热水WMI 一调用就有数据。管理员用 PowerShell 一句Get-WmiObject Win32_Process就能拉出全部进程程序员用 C# 写几行代码就能远程查百台服务器的内存使用率安全工具靠它实时监控服务启停甚至 Windows 自身的“性能监视器”“事件查看器”“系统配置实用工具msconfig”背后都连着 WMI 这根数据动脉。很多人第一次听说 WMI是因为弹出一个报错“WMI Provider Host 占用 90% CPU” 或 “WMI 服务未运行”。这时才意识到原来这个“看不见的体检系统”不仅在提供数据它自己也是一套会喘气、会生病、需要维护的活体服务。搞懂 WMI不是为了写底层驱动而是为了真正看懂 Windows 的“身体语言”——它告诉你系统在想什么、正在做什么、哪里卡住了、谁在偷偷改配置。这不是运维老手的玄学黑匣子而是一份你本该拥有的、Windows 原生的“系统说明书”。2. WMI 为什么存在当 Windows 需要一套“通用语言”来管自己2.1 没有 WMI 的年代每个工具都在自说自话在 WMI 出现之前Windows 管理就像一个没有统一翻译的国际会议查进程用tasklist.exe输出是纯文本字段位置固定但难解析查磁盘空间用df.exe或第三方工具格式又不一样查服务状态得调sc query返回一堆状态码还得查文档才知道4是“运行中”想写个脚本自动重启某服务得拼接命令、解析字符串、处理空格和换行——稍有不慎就翻车。更麻烦的是这些工具彼此隔离tasklist不知道sc查到的服务属于哪个进程df更没法告诉你哪个进程正在疯狂写入那个快满的磁盘。系统内部的数据像散落在不同抽屉里的纸条没有索引、没有关联、没有标准格式。开发者想做个统一监控面板得为每个功能单独适配一种接口写三套解析逻辑维护成本高到劝退。提示这种“碎片化管理”正是 WMI 要解决的根本问题——它不替代tasklist或sc而是给它们背后的数据统一贴上“身份证”和“说明书”。2.2 WMI 的三层设计让数据从“能用”变成“好用”WMI 不是简单把命令输出包装一下它用一套严谨的三层结构把杂乱数据变成可编程、可查询、可扩展的资产① 数据层CIM 模型——给万物贴上标准标签WMI 采用 DMTF分布式管理任务组制定的CIMCommon Information Model标准把硬件、软件、服务、用户、网络……统统抽象成“类Class”和“实例Instance”。比如Win32_OperatingSystem是一个类定义了“操作系统该有哪些属性”Caption系统名、TotalVisibleMemorySize总内存、LastBootUpTime上次启动时间你电脑上的 Windows 11 就是这个类的一个实例它的Caption值是Microsoft Windows 11 ProTotalVisibleMemorySize是1717986918416GB。这就像给每台设备发一张带二维码的工牌不管你是戴尔、联想还是自组装只要扫一下Win32_ComputerSystem这张工牌就能立刻读出Manufacturer厂商、Model型号、NumberOfProcessorsCPU 核心数——格式完全一致。② 接口层多种语言都能“说人话”WMI 提供多套 API让不同技术栈的人都能轻松调用脚本层VBScript、PowerShell 直接用对象语法如$os Get-WmiObject Win32_OperatingSystem; $os.LastBootUpTimeCOM 层C/VB6 程序员通过 COM 接口访问像操作 Excel 对象一样操作IWbemServices.NET 层C# 开发者用System.Management命名空间一行new ManagementObjectSearcher(SELECT * FROM Win32_Service)就搞定命令行层wmic命令虽已标记为“过时”但仍是理解 WMI 的快捷入口。关键在于所有接口访问的是同一份底层数据。你在 PowerShell 里查到的进程列表和 C# 程序里拿到的是同一个 WMI 存储库Repository里的同一组实例——不是各自抓取、各自解析。③ 扩展层任何人都能“加新科室”WMI 最强大的地方在于它允许第三方“注册新科室”。微软自带Win32_Process进程、Win32_Service服务硬件厂商可以开发Dell_BatteryStatus类暴露笔记本电池健康度安全软件能注册AV_ThreatLog类让管理员用 WQL 语句直接查“过去24小时拦截的木马数量”甚至你自己写个 C 程序实现一个MyApp_Configuration类把应用配置项变成 WMI 可查对象。这就是为什么文档里反复强调“WMI Providers提供程序是实现类功能的载体”。Provider 就像医院里各科室的医生——操作系统自带内科进程/服务、外科磁盘/网络、检验科性能计数器而第三方可以申请开设“AI诊断科”或“区块链审计科”只要按 CIM 标准交一份“科室说明书MOF 文件”WMI 就认。2.3 为什么现在还要学 WMI——它没被 PowerShell 取代而是成了它的“引擎”常有人问“PowerShell 都能Get-Process、Get-Service了还要 WMI 干嘛”答案很直白PowerShell 的Get-Process底层就是调的 WMI 的Win32_Process类。你可以验证# 这两者返回几乎相同的数据结构 Get-Process | Select-Object Name, Id, CPU Get-WmiObject Win32_Process | Select-Object Name, ProcessId, KernelModeTime区别在于Get-Process是 PowerShell 为你封装好的“快捷门诊”方便日常使用Get-WmiObject或更新的Get-CimInstance是直达“体检中心后台”的通道支持跨版本兼容、远程连接、复杂关联查询、自定义类访问——这是快捷门诊做不到的。举个真实场景某公司要审计所有域内电脑的 BIOS 版本是否低于1.25.0。用Get-Process完全无关。用 WMI# 一行搞定且能批量跑在1000台机器上 Get-CimInstance -ClassName Win32_BIOS -ComputerName $computers | Where-Object { [Version]$_.SMBIOSBIOSVersion -lt [Version]1.25.0 }WMI 是骨架PowerShell 是血肉。学 WMI不是倒退而是看清你每天敲的Get-命令到底在跟谁对话。3. WMI 和相似概念怎么区分别再把“体检报告”当成“体检医生”或“体检单”3.1 易混点①WMI vs PowerShell cmdlet —— “引擎”和“方向盘”的关系为什么混因为Get-WmiObject和Get-Process都在 PowerShell 里敲新手以为它们是并列的两种命令。怎么区分Get-Process是 PowerShell 团队写的独立模块它自己去调 Windows API 获取进程列表再格式化输出Get-WmiObject是 PowerShell 调用WMI 服务winmgmt由 WMI 去查Win32_Process类的实例再返回给你。→ 就像汽车Get-Process是厂商预装的车载导航自有地图算法Get-WmiObject是你插上手机用高德地图调用外部服务。前者快但功能固定后者慢一点但能查任何 WMI 支持的数据——包括你手机里没有的地图比如自定义的硬件类。3.2 易混点②WMI vs Windows Event Log事件日志—— “发生了什么”和“为什么发生”的分工为什么混两者都用于故障排查都出现在“事件查看器”里且 WMI 可以订阅事件日志变化。怎么区分维度Windows 事件日志WMI本质时间轴式记录日志条目对象状态快照类实例数据形态文本描述“服务 A 在 14:02:05 启动成功”结构化对象Win32_Service.NameA, StateRunning查询方式按时间、ID、来源筛选Event Viewer UI用 WQL 类 SQL 查询SELECT * FROM Win32_Service WHERE StateRunning典型用途追溯“何时出了错”实时监控“当前是否正常”→ 事件日志是“行车记录仪”WMI 是“仪表盘”。你想知道“刹车失灵是不是昨天发生的”看日志你想知道“现在刹车压力是否低于阈值”查 WMI。3.3 易混点③WMI vs Performance Counters性能计数器—— “静态快照”和“动态流”的互补为什么混Win32_PerfFormattedData_*这类 WMI 类名里带“Perf”看起来就是性能计数器。怎么区分原生性能计数器如\\Processor(_Total)\\% Processor Time由PerfOS、PerfProc等内核驱动实时采集数据是连续流单位是“每秒多少次”需用PerformanceCounter类持续采样WMI 性能类如Win32_PerfFormattedData_PerfOS_Processor是 WMI定期默认15秒从性能计数器拉取一次快照转成 CIM 对象。它牺牲了实时性换来的是可用 WQL 关联查询比如“CPU 使用率 90% 且内存使用 80% 的服务器”可跨命名空间关联比如把高 CPU 的进程Win32_Process和它的父服务Win32_Service连起来可被任何 WMI 客户端VBScript、C#、远程 PowerShell统一访问。注意WMI 性能类不是性能计数器的替代品而是它的“友好封装”。对实时性要求极高的场景如毫秒级监控仍需直连性能计数器对运维自动化、跨平台聚合、历史趋势分析WMI 性能类更省心。3.4 易混点④WMI vs Registry注册表—— “配置仓库”和“状态仓库”的边界为什么混很多 WMI 类的值如Win32_OperatingSystem.Caption明显来自注册表HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProductName。怎么区分注册表是 Windows 的配置数据库存的是“你希望系统变成什么样”如EnableLUA1表示开启 UACWMI是 Windows 的状态数据库存的是“系统此刻实际是什么样”如Win32_OperatingSystem.StatusOKWin32_ComputerSystem.DomainRole4表示是域控制器。虽然 WMI 会读注册表来生成某些属性但它绝不允许你直接用 WMI 修改注册表键值那是StdRegProv提供程序的职责且需显式调用SetStringValue方法。混淆二者会导致“以为改了 WMI 就改了配置”结果发现重启后一切复原——因为 WMI 只反映状态不承载配置。3.5 易混点⑤WMI vs DCOM / WinRM —— “数据协议”和“传输通道”的层级关系为什么混文档里总说“WMI 远程连接用 DCOM 或 WinRM”让人以为 DCOM 就是 WMI。怎么区分DCOM分布式 COM是 Windows 早期的远程过程调用协议像一条专用电话线WMI 用它把本地请求转发到远程机器的 WMI 服务WinRMWindows Remote Management是较新的基于 HTTP/HTTPS 的管理协议WMI 通过它走 WS-Management 标准更防火墙友好WMI 本身是运行在本地或远程机器上的服务winmgmt它不管你怎么连过来只负责接收请求 → 查存储库 → 返回结果。→ 类比快递WMI 是你的收货地址数据终点DCOM/WinRM 是顺丰或京东物流运输方式而Get-CimInstance是你下的订单请求动作。选哪家快递不影响你家地址本身。4. WMI 的核心能力拆解从“查数据”到“做事情”的完整链路4.1 查询WQL 不是 SQL但足够像到让你上手就用WMI 查询语言WQL专为 CIM 对象设计语法高度借鉴 SQL但做了关键精简不支持 JOIN因 CIM 用“关联类”实现关系非传统数据库表关联不支持 INSERT/UPDATE/DELETEWMI 主要面向只读查询写操作需调用方法支持 WHERE、ORDER BY、GROUP BY、BETWEEN、LIKELIKE %java%查含 java 的进程名支持 ASSOCIATORS OF / REFERENCES OF查关联对象如“查某进程的所有线程”。一个典型运维查询-- 查所有非系统进程非 SYSTEM、LOCAL SERVICE、NETWORK SERVICE 账户启动 SELECT Name, ProcessId, WorkingSetSize, CreationDate FROM Win32_Process WHERE NOT (Name LIKE svchost% OR Name LIKE winlogon% OR Name LIKE lsass%) AND NOT (GetOwner().User SYSTEM OR GetOwner().User LOCAL SERVICE OR GetOwner().User NETWORK SERVICE) ORDER BY WorkingSetSize DESC参数说明WorkingSetSize进程当前占用物理内存字节数CreationDateWMI 时间格式yyyymmddHHMMSS.mmmmmmUUU需用ConvertToDateTime()转换GetOwner()调用Win32_Process类的GetOwner方法返回启动该进程的用户名——这是 WQL 调用方法的特例体现其“面向对象”本质。4.2 执行不只是看还能让系统“动手干活”WMI 的强大在于它把“查询”和“操作”统一在同一个模型下。每个 WMI 类的方法就是系统开放的一个可控开关▶ 启动/停止服务比net start更精准# 获取服务对象 $service Get-CimInstance -ClassName Win32_Service -Filter NameSpooler # 调用 StartService 方法无参数 $service | Invoke-CimMethod -MethodName StartService # 调用 StopService 方法返回状态码0成功 $service | Invoke-CimMethod -MethodName StopService▶ 创建计划任务绕过 GUI全自动WMI 有Win32_ScheduledJob类但更推荐用MSFT_ScheduledTaskCIMv2 命名空间支持完整触发器# 创建一个每天早上8点运行 calc.exe 的任务 $task New-CimInstance -ClassName MSFT_ScheduledTask -Namespace Root/Microsoft/Windows/TaskScheduler -Property { TaskName DailyCalc Action New-CimInstance -ClassName MSFT_TaskActionExec -Property {Pathcalc.exe} Trigger New-CimInstance -ClassName MSFT_TaskTriggerDaily -Property {StartBoundary2023-01-01T08:00:00} } Register-CimInstance -InputObject $task▶ 修改 BIOS 设置需硬件支持高端主板提供WmiMonitorBrightnessMethods类可调屏幕亮度# 获取显示器亮度控制对象 $monitor Get-CimInstance -ClassName WmiMonitorBrightnessMethods # 设置亮度为70% $monitor | Invoke-CimMethod -MethodName WmiSetBrightness -Arguments {Brightness70; Timeout0}关键认知WMI 方法不是万能的。它能否执行某操作取决于Provider 是否实现了该方法如Win32_Service.StopService是微软实现的Dell_Battery.SetChargeThreshold是戴尔实现的调用者是否有足够权限常需 Administrator且 UAC 提权目标系统是否启用对应功能如 BIOS 设置需厂商提供 WMI 接口。4.3 订阅让 WMI 成为你的“系统哨兵”WMI 最被低估的能力是事件订阅——它能主动通知你“某事发生了”而非你每隔几秒去轮询。▶ 监控新进程启动防恶意挖矿# 订阅 Win32_ProcessStartTrace 事件无需重启服务 $query SELECT * FROM Win32_ProcessStartTrace WHERE ProcessName LIKE %miner% OR ProcessName LIKE %xmrig% $job Register-CimIndicationEvent -Query $query -SourceIdentifier MinerAlert -Action { Write-Host 检测到可疑挖矿进程 $event.SourceEventArgs.NewEvent.ProcessName -ForegroundColor Red # 这里可加入杀进程、发邮件、记日志等动作 }▶ 监控服务意外停止比 Windows 服务恢复更灵活# 当 Spooler 服务停止时触发 $query SELECT * FROM Win32_ServiceControlEvent WHERE ServiceNameSpooler AND EventType2 Register-CimIndicationEvent -Query $query -SourceIdentifier SpoolerDown -Action { Write-EventLog -LogName Application -Source WMI-Monitor -EntryType Warning -EventId 999 -Message Spooler 服务已停止正在尝试重启 Start-Service Spooler }优势对比传统轮询每5秒Get-Service SpoolerCPU 白耗延迟高最长5秒WMI 事件零轮询开销毫秒级响应且事件是内核级触发比用户态轮询更可靠。4.4 扩展自己动手丰衣足食——写一个最简 WMI ProviderWMI 允许开发者注册自己的类把任意数据源接入统一管理框架。以下是一个 C# 实现的极简 Provider 示例基于 .NET Framework// 1. 定义 CIM 类用 MOF 语法保存为 MyProvider.mof // #pragma autorecover // [dynamic, provider(MyProvider)] // class MyApp_Status { // [key] string InstanceID; // string Status; // uint32 UptimeSeconds; // }; // 2. C# Provider 实现继承 ManagementProvider [ManagementEntity(MyApp_Status)] public class MyAppStatusProvider : ManagementProvider { public override IEnumerableobject EnumerateInstances(ManagementOperationContext context) { // 返回一个实例模拟应用状态 yield return new MyApp_Status { InstanceID MyApp-001, Status Running, UptimeSeconds (uint)Environment.TickCount64 / 1000 }; } } // 3. 编译后用 MOF 文件注册到 WMI 命名空间 // mofcomp -n:root\cimv2 MyProvider.mof注册成功后即可用 PowerShell 查询Get-CimInstance -Namespace root\cimv2 -ClassName MyApp_Status # 返回InstanceIDMyApp-001, StatusRunning, UptimeSeconds123456为什么值得做把你自研应用的健康指标如连接池使用率、缓存命中率变成 Windows 原生可监控对象让 Zabbix、Nagios 等第三方监控工具无需额外 Agent直接通过 WMI 插件采集运维同事用Get-CimInstance MyApp_Status就能查不用记你应用的私有 API 地址和 Token。5. WMI 的实战边界什么时候该用什么时候该绕道走5.1 该用 WMI 的 4 个典型场景附真实踩坑经验✅ 场景①批量管理上百台 Windows 服务器的标准化运维需求某高校 IT 部门需每日检查 200 台实验室电脑的Windows 更新状态是否启用自动更新防病毒软件是否运行磁盘剩余空间是否 10GB是否安装了禁用软件如迅雷、Steam。为什么 WMI 是最优解所有数据均在Win32_OperatingSystem、Win32_Service、Win32_Volume、Win32_Product类中可用Invoke-Command批量执行 WMI 查询比逐台 RDP 登录快 100 倍输出为 PowerShell 对象可直接导出 CSV、生成 HTML 报告、触发邮件告警。血泪经验初期用Get-WmiObject远程查询遇到防火墙拦截就失败正确姿势改用Get-CimInstance -CimSession $session先创建 CIM Session自动协商 WinRM/DCOM并设置-OperationTimeoutSec 60防超时对Win32_Product类要谨慎——每次查询会触发 MSI 重校验导致远程机器卡顿改用Get-Package或查注册表更稳妥。✅ 场景②开发 Windows 服务的配套管理工具需求某公司开发了一个日志收集服务LogCollectorSvc需提供图形界面显示服务状态、最近10条错误日志按钮一键重启服务滑块调节日志级别Debug/Info/Error导出当前配置到 XML。为什么 WMI 是天然选择服务状态、进程 ID 可直接查Win32_Service自定义配置可通过LogCollector_Config类暴露用SetConfiguration方法接收新参数错误日志可映射为LogCollector_LogEntry类支持 WQL 查询WHERE LevelError AND TimeWritten 20230101。血泪经验别在服务主进程中直接实现 WMI Provider易导致服务僵死正确姿势将 Provider 作为独立 EXELogCollector.WmiHost.exe用wmiprvse.exe托管或注册为 Windows 服务调试时用wbemtest.exeWMI 测试器连接root\cimv2手动执行GetObject和ExecMethod比调试 GUI 快得多。✅ 场景③安全审计与合规检查需求等保 2.0 要求检查本地管理员组是否包含非必要账户远程桌面是否启用USB 存储设备是否禁用系统日志保留天数是否 ≥ 180 天。为什么 WMI 是合规利器Win32_GroupUser关联查管理员组成员Win32_TerminalServiceSetting查 RDP 状态Win32_USBControllerWin32_PnPEntity查 USB 设备Win32_NTEventLogFile查日志文件大小和覆盖策略。血泪经验Win32_GroupUser返回的是 SID不是用户名需用Win32_Account关联转换正确姿势用ASSOCIATORS OF语句一步到位ASSOCIATORS OF {Win32_Group.Domain.,NameAdministrators} WHERE AssocClassWin32_GroupUser ResultClassWin32_UserAccountUAC 会影响结果普通用户查不到Win32_Service的StartMode必须以 Administrator 运行脚本。✅ 场景④嵌入式设备或 IoT 网关的轻量管理需求某工业网关运行 Windows IoT Core需通过 Web 页面展示CPU/内存实时使用率串口设备连接状态COM1/COM2自定义传感器读数温度、湿度。为什么 WMI 是轻量首选Windows IoT Core 默认启用 WMI无需额外安装 AgentWeb 后端Node.js/C#用node-wmi或System.Management直接调用比开 HTTP API 更省内存传感器数据可通过自定义 Provider 注册Web 端用 AJAX 轮询GET /wmi?classSensor_Temp即可。血泪经验IoT Core 的 WMI 存储库较小避免注册过多类正确姿势将多个传感器合并为一个类Sensor_Reading用SensorType属性区分Temp/Humidity减少类数量启用 WMI 的__InstanceModificationEvent订阅Web 端收到变更再刷新比轮询更高效。5.2 该绕道的 3 个危险区踩坑即后悔❌ 危险区①高频实时监控 1秒粒度问题想用 WMI 每 100ms 查一次 CPU 使用率做实时性能仪表盘。后果WMI 查询本身有开销序列化、COM 调用100ms 频率会导致wmiprvse.exeCPU 占用飙升甚至阻塞其他 WMI 请求。绕道方案改用 .NETPerformanceCounter类直接读内核性能计数器或用 Windows ETWEvent Tracing for Windows采集Microsoft-Windows-Kernel-Processor事件精度达微秒级。❌ 危险区②查询Win32_Product类进行软件盘点问题用Get-CimInstance Win32_Product获取所有已安装软件。后果该类每次查询会触发 Windows Installer 的全盘扫描验证每个 MSI 包的完整性导致单次查询耗时数秒至数分钟远程查询可能使目标机器假死大量并发查询引发 WMI 服务崩溃。绕道方案查注册表HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\*32位和HKLM:\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*64位或用 PowerShellGet-Package需 PackageManagement 模块企业环境用 SCCM 或 Intune 的原生软件清单。❌ 危险区③跨平台管理Linux/macOS问题想用同一套 WMI 脚本管理 Windows Linux 服务器。后果WMI 是 Windows 专属技术Linux/macOS 无原生支持虽有 OpenPegasus 等开源实现但兼容性差、无人维护。绕道方案统一用AnsibleSSH 协议跨平台或用REST API 自定义 Agent如 Prometheus Exporter若坚持用 PowerShell改用Invoke-Command -HostNameSSH或Invoke-RestMethod调 Linux 的/api/system/status。5.3 我的强制习惯每次写 WMI 脚本前必做的 3 件事从那以后我每次写涉及 WMI 的自动化脚本都强制走一遍这三步再没因环境差异翻过车第一步确认命名空间和类是否存在# 不直接查先验证基础 $ns Get-CimInstance -Namespace root\cimv2 -ClassName __NAMESPACE -Filter Namecimv2 -ErrorAction SilentlyContinue if (-not $ns) { throw 命名空间 root\cimv2 不可用请检查 WMI 服务 } $class Get-CimClass -Namespace root\cimv2 -ClassName Win32_Process -ErrorAction SilentlyContinue if (-not $class) { throw Win32_Process 类不存在请检查操作系统版本 }第二步测试远程连接通道# 优先尝试 WinRM现代、安全 try { $session New-CimSession -ComputerName $target -SessionOption (New-CimSessionOption -Protocol Wsman) -ErrorAction Stop Write-Host WinRM 连接成功 } catch { # WinRM 失败则降级 DCOM $session New-CimSession -ComputerName $target -SessionOption (New-CimSessionOption -Protocol Dcom) -ErrorAction Stop Write-Host DCOM 连接成功降级 }第三步加超时和重试拒绝无限等待$opt New-CimSessionOption -OperationTimeoutSec 30 $session New-CimSession -ComputerName $target -SessionOption $opt # 查询时捕获超时异常 try { $procs Get-CimInstance -CimSession $session -ClassName Win32_Process -OperationTimeoutSec 15 } catch [Microsoft.Management.Infrastructure.CimException] { if ($_.Exception.Message -match timeout) { Write-Warning $target 查询超时跳过 continue } else { throw } }希望帮到你。本文还有配套的精品资源点击获取