设置里看不到的那部分启动项

Autoruns 属于微软 Sysinternals 工具集，免费提供。它按自启机制分成多个视图，Phillips 先打开的是 Logon 视图，看开机登录时被配置为自动运行的项目。这里既有他预期中的条目，也有一些一眼认不出来的名字。

真正的差异出现在 Packaged Apps 标签页。Windows 应用可以注册属于自己的启动任务，而这类任务并不会出现在「设置 – 应用 – 启动」的列表里。Phillips 在这个标签页下找到了若干设置界面完全没有显示的自启项。

值得注意的是他接下来的做法：没有把不认识的条目一律取消勾选，而是逐条去查清各自的用途。理由很直接，名字陌生不等于无关紧要，有些条目指向的是 Windows 自身组件或系统级启动任务，盲目关掉可能影响正常功能。

没打开的程序，其实早就在后台跑

第一个被揪出来的是 Slack。Autoruns 的 Packaged Apps 标签页里有一个名为 SlackStartup 的条目，对应 Slack 的打包版 Windows 应用。开机之后，Phillips 在任务管理器里看到七个 slack.exe 进程，合计占用约 380MB 内存——而他并没有主动打开过 Slack。在 Autoruns 里禁用这个启动项并重启，任务管理器的进程列表中，那七个 slack.exe 全部消失。

Microsoft 365 Copilot 是另一个例子。同样是没有主动打开，开机后却已经占掉相当一部分内存。禁用对应启动项后，下次重启它不再自动加载。

这两个案例说明的是同一件事：一个被配置为自动启动的程序，可能在用户登录完成时就已经在后台运行了，哪怕界面从未出现过。不过 Phillips 也强调，这并不意味着 Autoruns 里翻出来的每一条都该禁用。

关掉一处，不等于关掉全部

Microsoft Teams 的情况更能说明问题的复杂程度。Autoruns 的 Logon 标签页里有两个 Teams 条目，都指向 ms-teams.exe。Phillips 追查后发现它们来自 Windows 的 Run 注册表键，那里有一个 Teams 值负责拉起程序。

他在 Autoruns 中取消勾选，并确认注册表里的 Teams 值随之消失。看起来问题解决了，于是他重启电脑，全程没有手动打开 Teams——但 Teams 依然在后台运行，任务管理器里出现两个 ms-teams.exe 进程，分别占用约 2MB 和 38MB。再回头查注册表，那个 Teams 值又回来了。

顺着这条线继续找，他在 Windows 的打包应用启动数据中发现了 TeamsTfwStartupTask。更关键的是，Teams 自身的 Windows 设置里，「登录时运行」这个开关始终没关。也就是说，Autoruns 确实成功移除了他所选中的那个启动项，但同一个程序还有另一条自启路径在起作用，注册表值之所以复原，正是因为源头没被处理。

三个工具各管一段

跑完这一轮，Phillips 给出的结论不是「用 Autoruns 取代原有工具」，而是三者分工：

• 设置 – 应用 – 启动：管理普通应用的登录自启，日常够用；
• 任务管理器：看当下实际在运行什么，以及各自占用多少系统资源；
• Autoruns：看更完整的全貌，包括注册表启动项和打包应用的启动任务，这些未必出现在常规启动列表中。

他也提醒，翻出来的条目并非都值得禁用。这轮排查最大的收获是搞清楚了开机时究竟有哪些东西在启动，以及一个程序可以通过多少种不同的方式让自己开机就跑起来。对 Windows 用户来说，这也是了解微软 Sysinternals 工具集的一个理由。

来源：How-To Geek / Tony Phillips