简介：这是一份面向 Windows 开发与系统管理人员的英文 WMI 开发文档，适合需要理解管理数据模型、编写自动化脚本或开发管理应用程序的 C、C++、Visual Basic 及 .NET 开发者查阅。压缩包内仅含 1 个 PDF 文件，体积约 57.3MB，结构完整，便于离线检索与长期保存。文档从 WMI 体系结构入手，说明提供程序、存储库与客户端应用之间的关系，并讲解类、实例、属性、方法及与 COM 的关联；随后提供 WMI 类参考与命名空间说明，涵盖 Win32_OperatingSystem、Win32_Process 等常用类，以及 root\cimv2 的用途。文中还介绍 WQL 的基本语法与常见查询示例，并给出 PowerShell 使用方式和 C++、.NET 开发入口，可帮助读者建立从概念到查询、再到客户端开发的整体认知。已有 112 人学习。
1. 从大楼物业的台账说起：WMI 到底是什么
设想你刚搬进一栋写字楼，想知道这层还有几间空房、空调开没开、消防通道在哪。挨个敲门问显然不现实，但物业前台有一本台账，你只要报出「想看什么」，前台翻两页就能给答案。WMI 在 Windows 里扮演的就是这个前台加台账的角色：它把进程、服务、磁盘、网卡、事件日志、已装软件这些散落各处的信息，整理成一张张有名字的「表」，程序只要报出表名和筛选条件就能拿到结果，完全不用关心底层是谁在维护这些数据。这份 WMI 英文开发文档，就是这套机制最原始的说明书，讲的是怎么读表、怎么加表、怎么隔着网络读别人家的表。它值得搞懂，因为很多看起来玄学的「脚本查不到数据」「远程就是连不上」，根子都埋在这儿。
2. 为什么要有 WMI：一条管道背后的三层标准
如果每台机器、每个硬件厂商都用自己的方式汇报状态，管理脚本就永远写不完，换一台机器就得重写一遍。WMI 的设计思路是「标准先行」：先把「管理信息长什么样」「怎么问」「怎么答」这三件事定成公共约定，再让各家去实现。这份文档里反复出现 WBEM、CIM、COM 三个词，它们其实就是这三层约定的名字，搞清它们的先后关系，后面所有细节都会顺很多。
2.1 WBEM：先有「怎么管」的行业共识
WBEM 的全称是 Web-Based Enterprise Management，直译过来是「基于 Web 的企业管理」，但它真正想解决的问题跟网页没多大关系：企业环境里的机器、设备、应用越来越多，每家厂商都有一套自己的管理接口，管理员被绑死在某个工具上。WBEM 是一份行业倡议，目标是发展出一套标准技术，让管理信息的访问方式统一起来。
打个比方，WBEM 像是插座的国标：它规定孔距、电压、形状，但不负责生产插座。至于插座是谁家做的、外壳什么颜色，标准不管。WMI 就是按这套国标做出来的那个具体产品，是 WBEM 在 Windows 操作系统上的实现。所以文档里那句话很关键：WMI 不是凭空冒出来的私有发明，它背后站着一整套行业标准。
这层关系带来的直接好处是「可迁移」。一个管理员在别的系统上学过的管理模型，到了 Windows 上能对应上号；一个开发者写的查询语句，换台机器大概率还能跑。标准的意义不在于它多先进，而在于它让所有人的预期对齐了。
理解了这一层，你就不会把 WMI 当成某个版本的附属功能，而会把它看成一套跨厂商约定的本地落地。后面提到的类名、命名空间、查询语法，全都是这套约定的具体表现形式。
2.2 CIM：拿面向对象的方式给一台机器画肖像
CIM 的全称是 Common Information Model，公共信息模型，由一家专门制定分布式管理标准的行业组织维护。它的做法很朴素：既然要描述系统、应用、网络、设备这些东西，那就用面向对象的方式描述,把每一类东西抽象成一个「类」，把具体某一台机器上的那个东西叫「实例」。
这个思路跟写代码几乎一样。Win32_Process是一个类，它定义「进程应该有名字、有进程 ID、有可执行文件路径」；你机器上正在跑的那个记事本进程，是Win32_Process的一个实例，属性填的是它自己的值。Win32_OperatingSystem描述操作系统，Win32_LogicalDisk描述逻辑磁盘，规律都一样。
CIM 最重要的一个特征是「语言无关」。它只规定模型长什么样，不规定你用什么语言去访问。所以你用 C++ 能查，用 C# 能查，用一段脚本也能查，查到的还是同一份数据。这跟「每个语言一套私有接口」是两种完全不同的设计哲学，前者把数据和管理逻辑解耦，后者把数据和调用方式绑死。
文档里提到 WMI 从 Windows 7 那一代开始兼容 CIM Schema 2.17.1，这句话翻译成人话就是：模型版本对上了，别人按标准写的类定义，在这套系统上能被正确理解。版本号这种细节平时用不上，但一旦你要写跨系统的管理工具，它就是绕不开的对齐点。
2.3 COM 与 DCOM：接口底座，以及远程为什么是重点
CIM 管的是「数据长什么样」，但数据总得有个通道送出来。WMI 的所有接口都建立在 COM（组件对象模型）之上，文档里说得很直白：不管是 Visual Basic、C++、ODBC 还是 ActiveX 的接口，底层都是 COM。COM 在这里的角色像电话线的接口规范，它规定插头怎么插、信号怎么传，至于你聊什么内容，它不管。
远程访问则走 DCOM。这是 WMI 真正值钱的地方，文档原话大意是：能从远程计算机获取管理数据，正是 WMI 有用的原因。想象一下你要同时看五十台机器的磁盘余量，一台台登录显然不现实，而一条远程查询就能把结果收回来。
DCOM 这条老路有两个现实麻烦：它依赖一批动态端口，防火墙规则不好写；跨网段、跨域的时候配置项多。所以文档里给了一个替代方案：WinRM，用基于 SOAP 的 WS-Management 协议来获取远程 WMI 数据。两条路的区别可以粗略理解成「专线」和「走通用快递」——前者历史悠久、生态成熟，后者穿透性和可管理性更好。
提示：看到这里就该建立一个印象，WMI 的「本地查询」和「远程查询」是两套配置语境。本地跑不通通常是类名或权限问题，远程跑不通十有八九是通道和身份的问题，别混在一起排查。
3. WMI 的内部构造：三个角色怎么把数据送到你面前
搞清了标准从哪来，接下来要看的是一台机器内部的分工。很多人第一次接触 WMI 会觉得它像个黑匣子：写一句话，数据就出来了。其实里面只有三个角色在转：发起请求的客户端、真正干活的提供程序、存放类定义的存储库。把这三个角色认全，出错时你至少知道该怀疑谁。
3.1 客户端、提供程序、存储库：点菜的、后厨和菜单
客户端是发起方，可以是一段脚本、一个 C# 程序、一个管理工具。它只负责说「我要什么」，不关心数据是从网卡上读的还是从注册表里翻的。
提供程序是真正干活的那一方。文档里点名了两个例子：启动配置数据提供程序、存储卷提供程序。规律是，每个 Windows 功能模块旁边通常都蹲着一个对应的提供程序，它把该功能的细节包装成 WMI 类的属性和方法。比如存储卷提供程序知道怎么问出每个分区的容量和剩余空间，客户端只管调它。
存储库则是放类定义的地方，可以理解成菜单：上面写着有哪些菜、每道菜什么配料，但菜本身不在菜单里。数据是查询那一刻由提供程序现取的，所以同一秒查两次可能拿到不同结果。
用餐厅打比方：客户端是点菜的客人，提供程序是后厨，存储库是菜单。客人翻菜单点菜，后厨现做，菜单本身不产生食物。这个分工解释了一个常见现象：某些类在你的机器上查不到，往往不是「数据没了」，而是「这道菜压根没写进菜单」，也就是对应的提供程序没装或者没注册。
注意：提供程序是独立的宿主进程，出问题时它可能自己崩掉而不影响系统其余部分。排查「某类查不到但别的类正常」时，这个细节能省下不少时间。
3.2 命名空间：root\cimv2 为什么几乎天天见
命名空间是类的分组容器，作用跟文件夹一模一样：避免重名，也方便按主题归类。文档里明确提到，root\cimv2是最常用的那个命名空间，绝大多数以Win32_开头的类都住在里面。
为什么要有分组？因为管理对象太多了。操作系统一层、安全一层、存储一层、电源一层，如果全堆在一个平面空间里，名字冲突几乎不可避免。命名空间让不同团队可以各自定义自己的类，只要落在不同的「文件夹」里就互不干扰。
这个设计也解释了另一个高频困惑：为什么有的脚本要显式写命名空间，有的不用。原因在于默认值。多数工具默认连root\cimv2，所以你写类名就能跑；一旦目标类在别的命名空间里，就必须把完整路径带上，否则会得到「类不存在」这种看起来很像权限问题的报错。
实际写脚本时，命名空间的写法是反斜杠分隔的层级，比如root\cimv2。看到这种斜杠组合，你就知道它在指路，而不是在写文件路径。
3.3 类、实例、属性、方法：四层对象模型怎么读
这套对象模型的四个词，用一张表对照着看最省事：
| 概念 | 含义 | 例子 |
|---|---|---|
| 类 | 一类事物的模板 | Win32_Process |
| 实例 | 模板落到具体对象上 | 某个正在跑的进程 |
| 属性 | 描述实例的数据字段 | 进程名、进程 ID |
| 方法 | 实例能执行的动作 | 创建进程、终止进程 |
属性和方法的区别值得单独说一句：属性是「读出来的信息」，方法是「按下去的动作」。查进程名是读属性，结束一个进程是调方法。文档在讲 WMI 类参考时，每个类都会列出这两部分，看文档时先分清哪些是能读的、哪些是能做的，心里就有谱了。
类和实例的区分则决定了查询的写法。你查的永远是实例，因为只有实例才对应真实的机器状态；类只在你需要知道「有哪些字段可查」时才去翻。
4. 开口说话的方式：WQL 查询与几种开发入口
认完内部构造，就到了实际开口的环节。WMI 提供了一套查询语言，也提供了从脚本到编译型语言的多种入口。不同入口的差别不在能力，而在你手上正好有什么工具、想解决什么问题。这段内容对写过 SQL 的人特别友好，因为语法长得非常像。
4.1 WQL：长得像 SQL，但它只是查询语言
WQL 是 WMI 的查询语言，结构跟 SQL 高度相似：SELECT挑字段，FROM指定类，WHERE加条件。下面这条是文档里常见的查询形态，用来挑出某个具体进程：
-- 从进程类里挑出名字等于 notepad.exe 的实例，只要名字和进程 ID 两个字段 SELECT Name, ProcessId FROM Win32_Process WHERE Name = 'notepad.exe'三个部分的含义分别是：SELECT后面跟属性名，多个用逗号隔开，写*表示全要；FROM后面必须是一个类名，不能是实例；WHERE后面是筛选条件，字符串要用单引号包起来。这里最容易翻车的地方是引号：SQL 习惯用单引号包字符串，如果你在命令行里再套一层引号，很容易被解析器吃掉。
WQL 的定位要说清楚：它是查询语言，不是完整的 SQL。它没有JOIN，也不负责改数据。想改数据得走类的方法，不是靠一条UPDATE语句。这一点初学者最容易误解，以为学会了 SQL 就等于学会了 WQL，结果在语法上卡很久。
还有一类查询容易被忽略：查关联。文档在讲跨命名空间关联遍历时提到，可以通过标准机制去发现配置档案。通俗地说，就是「顺着关系找」，比如从磁盘找到它所属的卷，再找到卷所在的控制器。这类查询写起来比单表查询绕，但遇到需要串起多个对象的场景时，比手工拼装数据干净得多。
4.2 从脚本到 C++：几种入口分别适合谁
文档里明确说了，开发 WMI 脚本或应用不需要另外下载安装专门的开发工具包，系统自带的能力就够用。这个细节很实用，意味着门槛比想象中低。
对绝大多数人来说，最快的入口是 PowerShell。文档里专门点出，很多管理员通过 PowerShell 访问 WMI，Get-WmiObject这类命令能取本地或远程存储库里的信息。下面这段查本机进程：
# -ClassName 指定要查的类，管道交给 Select-Object 只保留两列 Get-CimInstance -ClassName Win32_Process | Select-Object -Property Name, ProcessId-ClassName是类的名字，必须是真实存在的类；管道后面的Select-Object决定输出哪几列，不加的话会返回一大堆属性，屏幕刷得看不清。这里用Get-CimInstance而不是老的Get-WmiObject，是因为前者走的是更新的接口层，和后面要说的 MI 是一条线上的。
C# 这类托管语言的入口也不复杂，靠的是System.Management这组类型：
// 用一条 WQL 构造查询器，Get() 拿到结果集合 using System.Management; var searcher = new ManagementObjectSearcher( "SELECT Name, ProcessId FROM Win32_Process"); foreach (ManagementObject item in searcher.Get()) { // 属性取值是 object 类型，拿到的可能是字符串也可能是数字 Console.WriteLine($"{item["Name"]} -> {item["ProcessId"]}"); }构造ManagementObjectSearcher时传入的是 WQL 字符串，Get()返回一个集合，遍历时每一项都是一个实例。要注意属性取值返回的是object，直接当字符串用容易在某些字段上出问题，稳妥做法是显式转换。
至于 C++，文档提到开发者可以从「用 C++ 创建 WMI 应用」这个入口入手。C++ 走的是 COM 接口，代码量比脚本大得多，适合要嵌进既有系统、或者对性能有要求的场景。文档还提到，熟悉 COM 编程会有帮助，但不是必需的,这句话对新手挺友好，说明门槛是可以逐步跨过去的。
4.3 远程与权限：连不上时先看这三处
远程是 WMI 的核心卖点，也是最容易卡住的地方。文档里反复提醒几个变量：用户账户控制会影响返回哪些数据、影响远程访问、也影响脚本必须以什么方式运行。这句话背后的意思是，同一条查询，用管理员身份跑和用普通身份跑，结果可能不一样。
第一处要看的是身份。脚本以什么账户运行，决定了它能看见哪些命名空间、能读哪些类的属性。权限不足时，报错往往是「拒绝访问」，而不是「类不存在」,两者的排查方向完全不同。
第二处要看的是通道。远程走 DCOM 时，防火墙要放行对应的动态端口范围；改用 WinRM 时，要确认这条基于 SOAP 的通道本身是通的。文档里把 WinRM 列为 DCOM 的替代方案，实际选型时，跨网段场景用后者通常省心。
第三处要看的是系统版本差异。文档里专门列了「WMI 组件的操作系统可用性」这个条目，意思是某些组件在较新版本里可能不再默认安装，或者变成可选功能。查询报「类不存在」时，先确认这个类在当前系统上到底存不存在，比反复改权限有效得多。
提示：排查顺序建议是「身份 → 通道 → 类是否存在」。这个顺序的原理是从外到内，先确认你有没有资格问，再确认话能不能传过去，最后才确认问的东西在不在。
5. 五组最容易混淆的概念：别把 WMI 当成一个大一统的东西
这套体系里的名词密度很高，而且互相之间是包含、继承、替代、并存各种关系混在一起。很多人学不下去，不是因为难，而是因为把几个不同层级的东西放在同一个平面上比较。下面五组是最常混的，逐条拆开。
5.1 概念层：WMI、WBEM、CIM 谁包含谁
易混点：把这三个当成同义词，或者以为 CIM 是 WMI 的旧名字。
为什么混：三者经常在同一段话里出现，而且都跟「管理」有关，文档里也不会每次都解释一遍。
怎么区分：按「标准 → 模型 → 实现」的顺序排。WBEM 是那份行业倡议，管的是「要有统一的管理信息访问方式」这件事；CIM 是模型规范，管的是「系统、应用、设备怎么用面向对象的方式描述」；WMI 是落地实现，管的是「在 Windows 上具体怎么查、怎么改」。一句话记法：WBEM 是理念，CIM 是图纸，WMI 是盖好的房子。文档里那句「WMI 是 WBEM 的实现」就是这个意思，而 CIM 是 WMI 用来描述世界的语言。
5.2 代际层：WMI 和 MI 是新旧替代还是并存
易混点：看到「下一代」三个字，就以为 WMI 要被淘汰了，学它没意义。
为什么混：「下一代」这个词天然带着替代意味，加上文档里既说 MI 是新东西，又说它完全兼容旧版本，读起来矛盾。
怎么区分：抓「兼容」这个关键词。文档明确写了 MI 完全兼容此前的 WMI 版本，而且不少较新的提供程序是用 MI 框架写的，但依然能被 WMI 脚本和应用访问。所以真实关系是并存加兼容，不是推倒重来。对学习者来说，先学 WMI 的概念模型不会白费，因为 MI 沿用了同一套对象模型思路；对开发者来说，新写提供程序时可以优先考虑 MI 框架，理由是文档说的「设计和开发提供程序与客户端更容易」。
5.3 工具层：WMI 与 PowerShell、任务管理器差在哪
易混点：觉得 PowerShell 就是 WMI 的命令行版本，或者觉得任务管理器能看的東西 WMI 也能看，两者差不多。
为什么混：日常操作里它们经常同时出现，PowerShell 里那条查询命令的输出，跟任务管理器里看到的进程列表长得很像。
怎么区分：看层次。WMI 是底层的数据与管理基础设施，它不关心你怎么调用；PowerShell 是一个外壳工具，它内部可以通过 WMI 取数据，也可以走别的通道。任务管理器则是给人看的图形界面，它背后可能用了 WMI，也可能用了别的接口，你无法从界面上判断。判断方法很简单：凡是「换一种语言、换一个程序还能拿到同样数据」的，属于基础设施层；凡是「只在这个工具里能用」的，属于工具层。
还有一组容易被忽略的区别：WMI 和注册表。两者都能读出系统配置，但注册表是存储结构，WMI 是访问接口。有些 WMI 类的数据确实来自注册表，但更多类的数据是提供程序现算出来的，比如磁盘剩余空间就不可能存成静态值。把 WMI 当成「注册表的另一张皮」，会在遇到动态数据时彻底想不通。
6. 什么时候该翻这份文档，什么时候别翻
先说该翻的场景。第一种是你要写自动化脚本，需要批量获取本机或远程机器的状态：进程列表、服务状态、磁盘容量、已安装软件、事件日志。这类需求用 WMI 表达非常自然，一条查询就能拿到结构化结果，比解析命令行文本稳得多。第二种是你要开发管理类应用，需要用 C++、C# 或脚本语言去读取系统信息，文档里的类参考和方法说明就是字典。第三种是你遇到了「明明类名没错却查不到」的怪现象，需要翻「操作系统可用性」这类条目确认组件是否存在。
再说别翻的场景，这部分同样重要。如果你的目标是非 Windows 平台，这套东西根本不适用，硬啃只会浪费时间。如果你要做的是高频、毫秒级的实时监控，WMI 不是合适的选择，它更适合按需查询而不是持续采样。如果你只是想知道某个进程占了多少内存，任务管理器点一下就行，没必要为了一个数字去写查询。还有一类情况：你误把 WMI 当成配置管理的唯一真相源，把所有配置都往里塞，最后会发现它擅长的是「读状态」，不是「存配置」。
下面这张表可以贴在便签上：
| 场景 | 适合用 WMI | 更合适的替代 |
|---|---|---|
| 批量取多台机器磁盘余量 | 是 | 无 |
| 毫秒级性能采样 | 否 | 专用性能计数器接口 |
| 跨平台统一管理 | 否 | 跨平台管理框架 |
| 人工查看单个进程 | 否 | 图形化任务管理器 |
| 写提供程序接入新硬件 | 是 | 无 |
我自己的习惯是，动手写查询之前先花两分钟确认三件事：类在不在当前系统上、命名空间对不对、当前身份够不够。这三步走完再写代码，比写完跑不通再回头猜要快得多。有一次我为了一个「拒绝访问」折腾了半天权限，最后发现是命名空间写错了层级，那次之后我每次写远程查询都强制先把类名和命名空间单独验证一遍，确认能查通再往下加条件。这套笨办法救过我很多次。
这份英文开发文档本身也值得当范文看：它把「概述、体系结构、类参考、查询语言、故障排查」拆成清晰的分层，每一层只解决一个问题，不混着讲。如果你正好在写技术文档，它的章节组织方式就是不错的参考素材。需要这份完整资料的话，按页面上的获取方式自取即可。希望帮到你。
本文还有配套的精品资源，点击获取
