System Informer 实测：370 进程 230060 句柄 · 实测库

System Informer 4.0.26241.138 是 Windows 上的进程与内核对象查看器，压缩包 22089103 字节，里面按 amd64 / arm64 / i386 分了三个目录，amd64 主程序 SystemInformer.exe 4394512 字节。

它要解决的是任务管理器不够用：任务管理器能看到进程和 CPU 这 2 个层级，看不到进程背后的句柄、线程栈、加载的内核驱动，也看不到 SYSTEM 会话里那些以别的账户运行的进程。查一个文件为什么删不掉、一个端口为什么被占用、一个进程为什么杀不死，都得往下钻一层。

这次在带管理员令牌的会话里跑了一遍，量了 4 个维度的数据：首帧、进程和句柄的可读数量、它自己的资源占用、整机的内存与线程总数，并确认了没有管理员权限时它连标题栏都长不一样。

三种架构打在一个包里

官方 release 提供的 bin.zip 是 22089103 字节，解开是三个平级目录，每个目录都是一套完整的可运行文件，不是共享组件。

选对目录就能跑

64 位系统进 amd64，Windows on ARM 进 arm64，32 位系统进 i386。三个目录各有一份 Resources，里面最大的是 CapsList.txt，一份能力清单，用来把句柄权限位翻译成人话。

还有 peview.exe

amd64 目录里除了主程序，还有一个 peview.exe。它是独立的 PE 文件结构查看器，双击一个 exe 就能看节表、导入表、签名信息，不需要先开主窗口。

窗口 472 毫秒出来

从启动到主窗口可见用了 472 毫秒。这个数字比同类的 Electron 方案低一个数量级，因为它就是一张 Win32 表格，没有渲染进程也没有 JS 引擎。

首帧之后还有一轮填充

窗口 472 毫秒画出来的是框架，进程列表随后一批批填入。整个列表上屏的时刻没有单独计时，所以这 472 毫秒只代表程序起来了，不代表数据齐了。

进程树带层级缩进

列表默认按父子关系缩进，System 下面挂着 Registry、smss.exe、csrss.exe 这一串，一眼能看出谁是谁拉起来的。平铺模式也在同一个菜单里切。

标题栏里的 [Administrator]

主窗口标题是 System Informer (...) [Administrator]，方括号里的字样就是当前令牌状态。这行字是整个工具能不能干活的分界线。

能展开 System 进程才叫有权限

截图里 System 那棵子树能展开出 Registry、smss.exe、Interrupts、csrss.exe 这些系统对象，说明内核驱动已经加载。普通权限下这一层是空的，只能看到 PID 4 一个孤零零的条目。

这一层要驱动才打得开

Registry、Interrupts 这些对象不在用户态，能列出来说明内核驱动已经加载。没有管理员令牌时驱动注册不上，这棵子树就是空的。

370 个进程、230060 个句柄

在同一台机器上用管理员令牌统计，可见进程 370 个，这 370 个进程的可读句柄加起来 230060 个，没有一个是拒绝访问。

句柄是任务管理器看不到的那一层

一个进程占着文件、注册表键、事件、互斥体这 4 个种类的对象，每一项都是一个句柄。文件删不掉的时候，要看的就是哪个进程拿着它的句柄，而不是哪个进程在跑。

230060 个句柄要按类型分

主窗口下面有句柄页签，能按 File / Key / Event / Section 分组。真正需要盯的是 File 和 Section 两类，前者锁文件、后者锁 DLL 和共享内存。

它自己占 76.3 MB

进程树展开后测它自己的资源：RSS 76.3 MB，CPU 2.1%，726 个句柄，10 个线程。

76.3 MB 是展开状态下的数

测的时候进程树全部展开、370 行都在，这个体积不能当成空窗口的占用。只开窗口不展开，看到的数字会比它小。

2.1% 只在你盯着看的时候有意义

这一次测的是进程树展开、列表持续刷新的状态。查一次句柄再关掉的话，这 2.1% 只存在几秒，不构成日常负担。

首次运行会停在介绍页

第一次启动不会直接给进程列表，先显示一页文件信誉分析的说明（与 Hybrid Analysis 的合作），要点一下或者按回车才进主窗口。

回车就够了

那页说明没有必须接受的勾选项，按 1 次回车就关掉，之后每次启动都直接进列表。它记录的是「已看过」，不是「已授权」。

灰行不是 bug

普通权限下能看到进程名字和 PID 这 2 个字段，内存、用户名、命令行这 3 个字段读不到，界面画成灰色而不是报错。想看到全部字段，必须以管理员启动。

三个目录加起来 52.9 MB

解压后三个架构目录各自独立，把它们的字节加起来是 52943839，而下载的压缩包只有 22089103，压缩比 2.4。同一份程序按三套指令集各编了一遍。

i386 比 64 位版小 8 MB

32 位目录 12320011 字节，amd64 是 20225898，两者差 7905887 字节。差别在指令编码密度和资源打包方式，功能列表是一样的。

arm64 反而最大

20397930 字节，比 amd64 还多 172032 字节。ARM 版要带一层兼容代码，体积略涨，跑在 Windows on ARM 的机器上才需要选它。

只留一套能省一半空间

52943839 里真正要用的只有一套。amd64 机器上把另外两个目录删掉，占用从 52.9 MB 降到 20.2 MB，程序行为不变。

这台机器的底账：19.8 GB 内存、7183 个线程

用同一套权限把整机统计出来，进程 373 个，线程合计 7183 个，所有进程的常驻内存加起来 20245 MB，也就是 19.8 GB。

procs    373
threads  7183
rss_total 20245 MB
rss_top5  2803 MB
threads_max 518

5 个进程吃掉 2.74 GB

373 个进程里内存最大的 5 个加起来 2803 MB，占整机常驻内存的 14%。剩下 368 个进程平摊另外 86%，这就是为什么任务管理器里排序一开，前排永远是那几个。

7183 个线程摊在 373 个进程上

平均每个进程 19 个线程，实际分布极不均匀：线程最多的一个进程占 518 个，而大量后台进程只有个位数。线程数异常飙升通常意味着某个进程在反复创建又不等回收。

先确认自己带没带令牌

启动之前先查一次，省得开了窗口才发现列表全是灰的。一条命令行就能回答，不用装任何东西。

powershell -Command "([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)"

True 之后再看窗口标题

命令返回 True 只说明这条会话有权限，实际启动的进程有没有继承要看标题栏。带方括号才是真的进去了，一眼就能确认。

False 时先查残留实例

以管理员方式启动后仍然是 False，通常是旧进程还挂在托盘里，新启动的窗口交给了它。任务管理器里把同名进程全部结束，再启动 1 次。

窗口里排着 6 列

主窗口打开后是一次性铺满的界面：顶部 5 个菜单，右上角一个搜索框，中间一张进程表，每行 6 个字段。

窗口拉到 2540 像素宽时，一屏大约排下 30 行进程，370 个进程要滚动 12 屏才到底。截图里这一屏正好覆盖从 System Idle Process 到前几个浏览器进程。

System 那一行不是普通进程

PID 4 的 System 展开后挂着 Registry、smss.exe、Interrupts、csrss.exe，这些是内核对象和早期进程，任务管理器里看不到这一层。能展开出这几项，说明驱动已经就位。

搜索框在右上角

输入框位于工具栏最右侧，旁边是图标尺寸和刷新相关的 2 个按钮。这张截图里 6 列全部可读，说明当时读的是提升后的令牌。

amd64 目录里 Resources 占 792K，单是 CapsList.txt 就有 2 万多个字节，其余是图标与主题资源。这份清单决定了权限位能不能翻译成可读的文字。

菜单栏只有 5 项

System、View、Tools、Users、Help 各一项，进程操作集中在 System 下面，列显示与刷新间隔在 View 下面，两者分工很明确。

什么场景值得上

任务管理器能回答「谁在吃 CPU」，它回答的是「谁拿着这个文件」「这个端口归哪个进程」「这个 DLL 被谁加载了」。

它比任务管理器多一层

任务管理器停在进程层，它往下挖到句柄和线程这 2 个层级，往上能看到内核驱动。分水岭就在这里：普通故障在进程层就能解决，解决不了的那些都需要往下走一层。

授权与费用

MIT 许可，个人和商业环境都不收费，源码在 GitHub 上，主要语言 C。标签里写着 administrator、debugger、monitoring、performance-tuning，功能范围比一个任务管理器宽得多。