企业官网建设流程全解析

WMI Explorer：图形化执行 WQL 查询，快速定位 Windows 系统故障

【免费下载链接】slickthe last carousel you'll ever need项目地址: https://gitcode.com/GitHub_Trending/sl/slick

凌晨两点，一台 Windows 服务器上的业务服务反复启动失败，命令行只抛出一个笼统的错误码，翻日志又没头绪。这时候打开 WMI Explorer——图形化执行 WQL 查询、做 Windows 系统监控和 WMI 故障排查的管理工具——把服务状态、启动账户、退出码、事件日志一条语句拉出来，问题十分钟就能定位。

这篇文章按"要干什么"来组织：先装好跑起来，再用四个高频场景把日常巡检跑顺，最后看脚本生成和远程连接怎么帮你省时间。

三步跑起来：安装、连接、找到查询面板

WMI Explorer 基于 .NET Framework 开发，拿到预编译版直接运行，没有配置向导要填。想从源码编译，把仓库拉下来即可：

git clone https://gitcode.com/GitHub_Trending/sl/slick

启动后自动连接本机 WMI 服务，左侧树里列着root\CIMV2、root\SecurityCenter2这些命名空间。界面一共五个区域：左侧命名空间树，中间类和实例列表，右侧属性面板显示选中实例的每个字段，上方查询面板写 WQL，下方结果面板出数据。第一次用只需记一个动作——选中任意一个类，点生成查询，工具会直接写好SELECT * FROM 类名，之后改字段、加条件就行。

命名空间、类、实例：三句话讲清 WQL 查询语句怎么写

WQL 看着像 SQL，真正要理解的是它取数的方式。拿一家公司打比方：命名空间是部门，root\CIMV2这个"信息中心"装着操作系统、硬件、进程这些最常用的类；类是岗位模板，Win32_Process规定了进程该有名字、PID、内存占用这些字段；实例是在岗的人，你机器上每个正在跑的进程就是一条实例。

对应到语句上：FROM指定类，WHERE过滤实例，SELECT挑字段，ORDER BY排个序。四件套齐了，后面所有查询都是这个句式在变。

四个高频场景，各给一条能跑的 WQL

日常 80% 的排查集中在进程、服务、硬件、远程机器这四类。下面每个场景一条主查询，照着改条件就能用。

查进程：一条 WQL 揪出吃内存的大户

怀疑内存被谁吃掉？按工作集大小倒排一次，前三名基本就是答案：

SELECT Name, ProcessId, WorkingSetSize FROM Win32_Process ORDER BY WorkingSetSize DESC

结果面板看 WorkingSetSize 这一列，单位 KB，排在最上面的就是占用大户。要盯某个具体进程，在语句里加一行WHERE Name LIKE '%chrome%'，过几分钟重跑一次：数值持续上涨，内存泄漏基本可以坐实。

查服务：起不来的服务，状态和日志一次看全

回到开头的场景：服务起不来时，别只盯命令行那句"启动失败"。先查状态、启动类型、启动账户、退出码：

SELECT Name, State, StartMode, StartName, ExitCode FROM Win32_Service WHERE Name = 'YourService'

ExitCode 是关键——1053 通常指向服务没及时响应控制请求，StartName 的账户权限对不上时先怀疑配置。再补一条系统日志查询，时间线就完整了：

SELECT EventIdentifier, Message, TimeWritten FROM Win32_NTLogEvent WHERE LogFile = 'System'

看 TimeWritten 和服务报错时间对齐的那几行，Message 里往往直接写着失败原因。

盘点硬件：内存和磁盘容量两条语句摸完家底

新机器接手或故障复盘，先把家底摸一遍。操作系统版本加物理内存，一条语句出结果：

SELECT Caption, Version, TotalVisibleMemorySize, FreePhysicalMemory FROM Win32_OperatingSystem

TotalVisibleMemorySize 减去 FreePhysicalMemory，就是当前物理内存压力，单位 KB。磁盘容量看逻辑盘：

SELECT DeviceID, Size, FreeSpace FROM Win32_LogicalDisk WHERE DriveType = 3

DriveType = 3 表示本地磁盘，Size 和 FreeSpace 都是字节，除以 1073741824 换算成 GB，再判断剩余空间够不够。

连远程机器：三步查一台不在手边的服务器

远程 WMI 查询不需要在目标机器上装任何代理。第一步点连接，输入对方机器名或 IP，按需填凭据；第二步连上后，左侧树会切换成远端的命名空间；第三步写查询——语句和本机完全一样，只是结果来自那台机器。

批量巡检时，对每台机器跑同一条"自动服务没在跑"的体检语句：

SELECT Name, State FROM Win32_Service WHERE StartMode = 'Auto' AND State != 'Running'

结果里出现的每一行，都是该自动启动却没在跑的服务，直接就是工单清单。

把重复查询交给 WMI Explorer：脚本生成加结果缓存

WMI Explorer 使用教程里最省时间的，是自动脚本这一项。选中一个查询结果，工具可以一键生成对应的 PowerShell 或 VBScript 脚本，查询逻辑原样保留——把上一条"自动服务没在跑"的查询生成脚本，丢进任务计划程序每天 8 点跑一次，有异常就发通知，一套最简的 Windows 系统监控就这么搭起来了，不用手写 WMI COM 调用。

第二项是结果缓存。枚举一个类的全部实例开销不小，工具会把枚举结果缓存下来，同一会话里反复查同一个类时不用每次全量拉取。配合远程连接批量巡检多台机器，前后耗时差距非常明显。

WQL 查不出结果？先排查这三个坑

• 权限不够。查事件日志和部分性能类需要管理员权限，连接成功但结果空着时，先以管理员身份重新打开工具试试；
• 命名空间不对。Win32_Service挂在root\CIMV2下，当前树停在别的命名空间时，同样的语句会查不到任何东西；
• 字段名打错。WQL 对字段名没有容错，对不上就是报错或空结果，稳妥做法是从右侧属性面板复制字段名，别手打。

下一步：把单次排查固化成例行监控

到此，本机 WMI 故障排查和远程巡检的完整链路都走通了。建议两个动作：把手头重复的查询用脚本生成固化成定时任务；再把常用 WQL 按"进程、服务、硬件、事件"四类存成清单，下次故障直接对号入座。更多细节和约定，看仓库里的 README.markdown。

【免费下载链接】slickthe last carousel you'll ever need项目地址: https://gitcode.com/GitHub_Trending/sl/slick