1. 一台说不清哪里不对劲的机器逼我把CMD捡了回来我平时远程连一台机器第一反应不是打开任务管理器点来点去而是先开一个 CMD 窗口敲几条命令。原因很简单图形界面给你的信息是被筛选过的命令行给你的是原始的。任务管理器里看到一个进程占着 30% 的 CPU你想知道它的完整命令行参数、启动用户、父进程、所在目录这些在界面上要点三四层在 CMD 里一条带筛选的tasklist或者wmic process就能一次性摊开。Windows 命令提示符里的系统信息查询和系统管理这两类命令本质上就是一套体检工具加手术刀前者负责看清家底后者负责动手干预。这篇是 CMD 系列的第二部分重心从文件目录操作挪到机器本身怎么在三十秒内摸清一台 Windows 的版本、补丁、内存、账户、服务、进程、磁盘占用出问题时用什么命令去定位、去干预、去收尾。我在生产环境里反复用过这套命令下面会尽量把为什么这么敲和敲完之后会发生什么讲明白而不是甩一张参数表让读者自己去猜。适合日常要维护几台到几百台 Windows 机器的人、写批处理脚本的人也适合被电脑很卡但不知道卡在哪困扰的普通用户。2. 系统底账先把机器的身份和家底问清楚2.1 systeminfo 的输出里真正有用的只有四行systeminfo是我登录一台陌生机器的第一条命令但它输出几十行很多人扫一眼就关掉了。实际上真正有诊断价值的只有四块内容OS 版本与构建号、系统启动时间、物理内存总量、热修复补丁列表。启动时间这一项尤其被低估一台本该常年不重启的服务器如果显示系统启动时间就在两小时前那说明它刚刚意外重启过后面所有的服务连不上都要先怀疑这个。构建号Build是判断系统版本层级的硬指标比Windows 10这种商品名靠谱得多。常见对应关系我整理了一下省得每次都要去翻资料构建号区间对应系统层级实用判断19041 - 19045较早期的桌面系统分支部分新组件默认不可用22000桌面系统的一个过渡分支界面改动大兼容性坑多22621 / 22631较新的桌面系统分支主流支持版本20348 / 25398服务器分支桌面组件默认缺失systeminfo支持远程查询参数是/s 目标机器 /u 用户名 /p 密码。但我得提醒一句这个命令远程跑起来很慢因为它背后要串行拉取一大串 WMI 类跨网段时等个二三十秒是常事。批量巡检场景下宁可写个循环配合超时控制也别指望它秒回。如果只想看补丁用wmic qfe list brief会快得多如果只想看系统名和版本wmic os get Caption,Version,BuildNumber /value一行就够。2.2 ver 分不出系统大版本这是个流传很广的误解很多人习惯敲ver看系统版本看到Microsoft Windows [版本 10.0.22631.3737]就以为知道是什么系统了。问题在于这一串版本号里的大版本号长期停留在 10.0不同代际的桌面系统都可能显示 10.0 开头光看ver你没法区分具体是哪一代。真正靠谱的取值位置在注册表reg query HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion /v DisplayVersion reg query HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion /v ProductName reg query HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion /v CurrentBuildDisplayVersion给出的是年度功能更新标识ProductName给出的是产品名CurrentBuild是构建号。这三条一起看基本不会有歧义。写成一行批处理也很方便for /f tokens2,* %a in (reg query HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion /v DisplayVersion ^| findstr DisplayVersion) do echo 系统版本: %bhostname和whoami是两个小到容易被忘掉的命令但在排障时很关键。多开远程会话的时候你经常需要确认我现在这条命令到底打在哪台机器上——hostname一眼就能确认。whoami更狠一点加上/all参数会把当前账户的 SID、所属用户组、启用/禁用的特权列表全列出来。我遇到过一个很典型的场景脚本明明在管理员账户下运行某个操作还是被拒绝whoami /all一看账户虽然在管理员组里但当前进程是以筛选后的令牌运行的特权列表里缺少SeDebugPrivilege之类的高危项。这种问题在图形界面上基本查不出来。2.3 set 不只是看环境变量它是定位路径类故障的快捷入口set不带参数会列出当前会话的全部环境变量输出很长但配合管道筛选就非常好用set | findstr /i path set | findstr /i temp我碰到最多的一类问题叫命令行能跑、双击脚本就跑不了九成是PATH在用户级和系统级之间打架或者某个工具的新版本把旧版本目录挤出了 PATH。用set path看清楚当前会话的实际拼接结果比在系统属性对话框里逐条比对快得多。还有一个更隐蔽的坑环境变量改了但没生效。这通常是因为你改的是系统级变量而已打开的 CMD 窗口继承的是启动那一刻的环境快照。批处理里如果依赖新加的环境变量最稳的做法是在脚本开头显式call一次刷新或者干脆用绝对路径别赌环境变量。2.4 wmic 的退场与替代写法wmic曾经是 CMD 下查硬件和管理系统的一把好手但它已经被标记为弃用新系统上默认可能不存在或者被裁剪。老脚本里大量出现它的身影所以还是得知道几个高频用法同时也得知道替代方案。高频的几条wmic logicaldisk get Caption,FileSystem,FreeSpace,Size wmic cpu get Name,NumberOfCores,NumberOfLogicalProcessors wmic memorychip get Capacity,Speed,Manufacturer wmic bios get SerialNumber,ReleaseDate wmic qfe list brief替代方案是 CIM 类查询在支持的命令行环境里写成powershell -NoProfile -Command Get-CimInstance Win32_LogicalDisk | Select-Object DeviceID,FileSystem,FreeSpace,Size | Format-Table我个人在家用和小规模场景里还是习惯用wmic因为它启动快、输出简单但在新机器上部署脚本时我会优先写 CIM 版本避免哪天机器升级后wmic直接报不是内部或外部命令。这个取舍没什么对错关键是别把整条排障链路押在一个已被标记弃用的工具上。3. 进程与服务把谁在吃资源这条链路走通3.1 tasklist 的筛选参数比任务管理器好用在哪tasklist默认输出进程名、PID、会话名、内存占用看着和任务管理器差不多。真正拉开差距的是/fi筛选器它支持按内存、CPU 时间、状态、会话、用户名做条件过滤tasklist /fi memusage gt 500000 /fo table tasklist /fi username eq 某账号 /v tasklist /fi status eq not responding tasklist /svc /fi imagename eq svchost.exe第一条命令列出内存占用超过 500MB 的进程单位是 KB所以 500000 大约是 488MB这个单位换算第一次用的人基本都会搞错。第三条筛出无响应的进程处理卡死窗口时比一个个点过去效率高得多。第四条是我最常用的svchost.exe一个进程名下面挂着几十个系统服务加/svc参数能把 PID 和它承载的服务名一一对应列出定位到底是哪个系统服务在闹事时必不可少。配合/fo csv和/nh不打印表头输出变
