inspired-by-atmosphere/ops-troubleshooting-skills/windows-autostart-diagnosis

Windows 开机自启与开机弹窗排查

用户报告"开机弹一堆终端/重启一次弹好几次"时，按本技能系统性盘点，别只盯着一个启动项下结论。

触发场景

• 开机时弹多个终端/黑窗口
• "XX 程序我没装自启它怎么开机自己开了？"
• 想让某个程序开机静默启动（不弹窗）
• 怀疑同一服务被自启两遍（进程冗余）

第〇步（新增·最重要）：修完启动项仍闪 = 弹窗源不在自启列表

实战教训（2026-08-18）：修完启动文件夹/Run/计划任务 + 关掉"恢复应用"（A+B+C 全做、每步实测验证），用户仍报告"疯狂闪终端、两个一起闪"。真正的元凶不在任何自启列表里，而是应用运行时自身拉起的前台控制台。所以先快照定位当前实际在弹什么，别只盯着启动项：

# 当前所有带标题窗口（数有几个终端/控制台窗口在弹）
powershell -NoProfile -Command "Get-Process | Where-Object {$_.MainWindowTitle -ne ''} | Select-Object Id,ProcessName,MainWindowTitle | Format-Table -AutoSize"
# 可疑进程计数（崩溃循环特征：进程数多 + 创建时间不断刷新）
powershell -NoProfile -Command "(Get-CimInstance Win32_Process | Where-Object {$_.CommandLine -match '关键词'}).Count"
powershell -NoProfile -Command "Get-CimInstance Win32_Process | Where-Object {$_.CommandLine -match '关键词'} | Select-Object ProcessId,CreationDate | Sort-Object CreationDate -Descending | Select -First 5 | Format-Table -AutoSize"

崩溃循环判定：同一命令进程数 >4 且创建时间在几分钟内反复新增 → 它在反复崩溃重启闪窗。常见两类隐藏弹窗源：

• MCP server 崩溃循环：Hermes config.yaml 里 mcp_servers: 配的 server 被 gateway/serve 反复拉起。实测 hermes-atlas-mcp（npx -y hermes-atlas-mcp，cmd→node 套娃）12 个进程循环重启，每实例闪 2 个 cmd 窗口 = "两个一起闪"。它只是给外部 MCP 客户端（Claude/Cursor）暴露目录用的，Hermes 本体用不到 → 移除即可。
• Dock 启动器拉起控制台程序：Winstep Nexus dock 项指向 hermes.exe（控制台程序），开机自启 dock → 启动时必弹终端打日志。

🛠️ 监控脚本：scripts/catch_popup.py（本技能自带）——监控 N 秒内新出现的 conhost/cmd/python/node 进程并打印父链+命令行，直接锁定"正在弹窗的进程是谁拉起的"。用法：python catch_popup.py 30。比静态猜启动点快得多，弹窗进行中时用它抓现场。

排查步骤（按序执行）

第一步：全量盘点自启位置（缺一不可）

一次查完，别挤牙膏。本机实测命令（git-bash）：

# ① 用户 + 公共 启动文件夹
ls -la "$APPDATA/Microsoft/Windows/Start Menu/Programs/Startup"
ls -la "$PROGRAMDATA/Microsoft/Windows/Start Menu/Programs/Startup"
 
# ② 注册表 Run 键
reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Run"
reg query "HKLM\Software\Microsoft\Windows\CurrentVersion\Run"
 
# ③ RunOnce（登录后只跑一次）
reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce"
reg query "HKLM\Software\Microsoft\Windows\CurrentVersion\RunOnce"
 
# ④ 计划任务（非禁用全列，注意中文/编码用 PowerShell）
powershell -NoProfile -Command "Get-ScheduledTask | Where-Object {$_.State -ne 'Disabled'} | ForEach-Object { Write-Output ($_.TaskPath + $_.TaskName) }"
# 计划任务详情（触发/动作）
powershell -NoProfile -Command "Get-ScheduledTask -TaskName 'X' | Select -Expand Triggers; (Get-ScheduledTask -TaskName 'X').Actions | Format-List Execute,Arguments"
 
# ⑤ 汇总命令（覆盖 ①②③）
powershell -NoProfile -Command "Get-CimInstance Win32_StartupCommand | Select-Object Name,Command,Location | Format-List"

第二步：判断哪种自启会弹窗口

弹窗元凶第一嫌疑：启动文件夹里的 .bat。一个 .bat 本身弹一个 cmd 窗口，里面的 start "" python ... 又弹一个，等于一个文件贡献 2 个窗口。

第三步：进程树溯源（谁在开机拉起谁）

# 拿到开机时刻附近被拉起的进程 + 它们的父进程
powershell -NoProfile -Command "Get-CimInstance Win32_Process | Where-Object {$_.Name -match 'hermes|python|node|cmd|WindowsTerminal'} | Select-Object ProcessId,ParentProcessId,Name,CreationDate | Sort-Object CreationDate | Format-Table -AutoSize"

• 父进程 = explorer.exe → 登录启动项 / Windows 恢复应用 拉起
• 父进程 = svchost.exe → 计划任务服务宿主拉起（去查计划任务）
• WindowsTerminal 标题是某程序名（如 "Hermes Desktop"）→ 查它父进程是谁、是不是计划任务开的
• 对比开机时间（事件日志 ID 12）与进程 CreationDate，能区分"开机自启" vs "用户手动点开"

第四步：查重复自启

同一服务既出现在启动文件夹 VBS、又在计划任务里 → 疑似双进程白吃资源。实测案例：hermes-gateway.vbs（启动文件夹）+ Hermes_Gateway（计划任务）都在启动 gateway。

⚠️ 两个启动器 ≠ 必然两个进程在跑：很多服务带"单实例锁"（如 Hermes gateway 启动前 find_gateway_pids()，已在跑就直接退出）。判断前先数实际进程数：

# 数真正的 gateway 进程（别数启动器）
powershell -NoProfile -Command "Get-CimInstance Win32_Process | Where-Object {$_.CommandLine -match 'gateway run'} | Select-Object ProcessId,ParentProcessId,CreationDate | Format-Table -AutoSize"
# 看锁/pid 文件指向谁（真正在跑的那个）
cat $HOME/AppData/Local/hermes/gateway.pid gateway.lock
# 看网络连接谁在监听/连着（gateway 例：6700 反向 WS）
netstat -ano | grep ":6700"

父子进程可能是一个"启动器"spawn 真正的实例（uv python 重执行），别被多个同名进程误导。

修复=二选一删一个。留哪个：优先留计划任务版——带完整环境变量（HERMES_HOME/PYTHONPATH/VIRTUAL_ENV）、有延迟（如 30s 等桌面稳定）、在任务计划程序里可见可管可重启；启动文件夹 vbs 通常是早期手工装的简陋版（裸 hermes.exe，无环境准备）。

第五步：删除冗余前的安全演练（证明备份通道真能拉起）

删掉一个启动器前，先实测证明剩下那条路真的能用——用户会担心"断掉一个是不是就断联了"，拍脑袋保证没用，要做一次安全演练（用户明确认可此方法）：

1. 记录现状：状态文件（如 gateway_state.json）/ 进程 PID / 端口监听（如 gateway 的 6700）
2. 停掉服务：powershell Stop-Process -Id <pid> -Force（⚠️ git-bash 里 taskkill //F 会被 MSYS 转义吃掉报"无效参数"，用 PowerShell 版）
3. 手动触发计划任务：Start-ScheduledTask -TaskName 'X'
4. 等 8-15 秒，验证：新进程起来、端口恢复监听、pid/lock 文件更新到新 PID、平台日志显示 connected
5. 通过 → 删冗余有实锤；失败 → 先修备份通道再动启动项

⚠️ 演练会闪断几秒服务（如 QQ 消息转发），动手前先跟用户确认时机。

删除启动器 ≠ 杀掉正在跑的进程：vbs/bat 是一次性"启动器"，干完活就退出；真正常驻的是被它拉起的服务进程。删启动器只影响"下次开机少一个触发点"，正在跑的服务完全不受影响。

第六步：自启只管"拉起"，看住常驻进程要另加监督层

核心事实（本机实测）：Windows 计划任务管不到分离式启动器拉起的进程。任务动作若是 wscript.exe <launcher.vbs>，而 vbs 末行是 sh.Run "<cmd>", 0, False（0=隐藏窗口、False=不等返回），wscript 在毫秒级以 0 退出 → 任务实例当场记"成功完成" → 任务 XML 里那条 <RestartOnFailure><Interval>PT1M</Interval><Count>999</Count> 永远只能观察到"启动动作本身失败"，对真进程是死是活一无所知；触发又往往只有 LogonTrigger、无任何存活探测。后果：进程静默消失（被杀/自退/崩溃，且常常不留任何应用层日志）后无人拉起，直到下次登录。

判据（导出真任务的 XML 看，别看任务计划程序界面的"已启用"）：

powershell -NoProfile -Command "Export-ScheduledTask -TaskName 'X'"   # 看 Triggers / RestartOnFailure / Actions.Exec

• Actions 是 wscript.exe <x.vbs> 且 vbs 里 ..., 0, False → 无监督，别信"任务里配了自动重启"。
• 顺带一条通用规律：很多常驻程序自己就假设"有个监督者"（Hermes gateway 的内部看门狗会 exit 75，注释写明是留给 service supervisor 重启的）。启动器一旦脱离，这条自退路径 = 永久停摆，而不是"自动重启"。

两种补法（可并存：轻的先上，重的后上）：

1. 存活看门狗（体积小、免提权，5 分钟级窗口）：另建一个每 5 分钟的计划任务 → 判活 → 不在就按原路径拉起 → 每班落一行日志 + 状态变化时通知。判活口径、脚本骨架、注册命令、演练方法见 references/daemon-supervision.md。
2. 真 Windows 服务（SCM 监督：崩溃即重启、开机即起不依赖登录、退出码有意义）：用现成轮子 NSSM 包装，配方见 references/daemon-supervision.md。⚠️ 服务与计划任务只能留一个启动者（单一 owner），否则两份进程抢端口；服务化时把原计划任务 /Change /DISABLE。

本步的两个硬坑

1. 注册计划任务：`schtasks /Create /XML` 要提权，CLI 形式才免提权。账号在 Administrators 但令牌是 Medium 完整性（未提权）时，/XML 报 错误: 拒绝访问，而 schtasks /Create /TN X /TR "..." /SC MINUTE /MO 5 /F 成功。代价是 CLI 形式带一堆不合适的默认值：DisallowStartIfOnBatteries=true + StopIfGoingOnBatteries=true（笔记本上等于永不运行）、StartWhenAvailable=false、ExecutionTimeLimit=72h。注册后必须补（schtasks /Change 改不了这些）：

powershell -NoProfile -Command "$s=New-ScheduledTaskSettingsSet -AllowStartIfOnBatteries -DontStopIfGoingOnBatteries -MultipleInstances IgnoreNew -StartWhenAvailable -ExecutionTimeLimit (New-TimeSpan -Minutes 5); Set-ScheduledTask -TaskName 'X' -Settings $s"

验证设置生效要看 (Get-ScheduledTask -TaskName 'X').Settings | ConvertTo-Json，不要看 schtasks /Query /V 的中文表（GBK 会乱码）。

1. 看门狗脚本的快路径禁止调 CLI：首版用 <服务> status 取判词，会把任务实例挂住（IgnoreNew 的任务一旦挂住 = 永久停止监督，且任务界面只显示"正在运行"看不出来）。判活改成直接读 pid/状态文件 + 身份校验（PID 存在 且 进程映像名匹配 且 记录里的启动时刻与进程实际启动时刻一致，容差几秒 → 防 PID 复用），单次 1 秒级；文件读不到时只记 PROBE-FAILED 不动作（宁可不救，也别乱起第二份）。

坑位

1. "重启后恢复应用"功能（用户级，默认开）：关机时开着的程序（如 Hermes Desktop）会在下次登录被 explorer 自动拉起，不在任何启动列表里，改启动项没用。注册表 HKCU\...\Explorer\Advanced\Start_TrackProgAndDesktop（空=默认启用）。关闭命令：reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced" /v Start_TrackProgAndDesktop /t REG_DWORD /d 0 /f。⚠️副作用：所有"上次开着"的程序都不会自动恢复了（浏览器/微信等），先跟用户说清。
2. `.bat` 改静默：不要试图在 bat 里藏窗口，直接改写成 .vbs（照抄已有 vbs 写法）：Set ws=CreateObject("WScript.Shell"): ws.Run "命令", 0, False。本机已有大量 vbs 范本可抄。写好后用 Windows 原生路径验证：cscript //nologo "%USERPROFILE%\x.vbs"（⚠️ 传 MSYS 风格路径会被当参数、报"未知选项"，必须写带盘符的全路径）。
3. schtasks/grep 中文输出乱码：用 Get-ScheduledTask 而非 schtasks 管道 grep；Get-CimInstance Win32_StartupCommand 可直接拿中文名。
4. git-bash 里 `taskkill //F` 无效（MSYS 转义吃参数报"无效参数/选项"）：用 powershell Stop-Process -Id <pid> -Force 或 taskkill /F（单斜杠+引号规避）代替。
5. 计划任务手动触发：Start-ScheduledTask -TaskName 'X'（PowerShell），触发后 gateway 常为"父启动器 spawn 子进程"形态，等 8-15 秒再验证端口/状态文件。
6. 改自启前先给用户方案确认，别直接删（本机 <data-drive>:\App 曾因误删丢 13 软件，删启动项同样要先确认）。方案里明说"可回滚"，并实际备份到 hermes/backups/。

坑位（续·2026-08-18 追加）

1. MCP server 崩溃循环（config.yaml 里 `mcp_servers:`）：这类 server 被 gateway/serve 反复拉起、崩溃重启就疯狂闪窗（实测 hermes-atlas-mcp 12 进程循环）。移除方法：

• ⚠️ config.yaml 是安全保护文件，patch/write_file 直接改会被拒（报 "Refusing to write to Hermes config"）。
• 用官方 CLI：hermes config unset mcp_servers.<name>（如 hermes config unset mcp_servers.hermes-atlas），再 grep 确认已清。
• 先备份：cp config.yaml backups/<日期>/。
• 移除后旧进程仍残留，等 gateway/serve 重启自然收敛（或手动 Stop-Process 止血）。
• ⚠️ 改 config 后运行中的 gateway/serve 不重读——持有内存旧配置继续拉 MCP server。必须重启 gateway（计划任务拉起，闪断几秒 QQ）才生效；serve 重启会中断当前桌面对话，慎做。

1. Dock 启动器拉起控制台程序 ≠ 恢复应用功能：桌面版若父进程是 Winstep Nexus（<install-dir>\Nexus.exe autostart）而非 explorer，那是 dock 项自启，不是 Windows 恢复功能。关 Start_TrackProgAndDesktop 对它无效！（8/18 实测：关掉恢复功能后桌面版仍被 Nexus 拉起——根因是 Nexus dock 项 1Path12=hermes.exe）。Nexus dock 项存注册表 HKCU\Software\WinSTEP2000\NeXuS\Docks（键 1PathN/1IconPathN/1StartPathN），配置目录 %USERPROFILE%\Winstep\ 与 %ProgramData%\WinStep\。
2. 控制台程序"静默启动"：hermes.exe desktop 是 Python 控制台程序，普通拉起必弹终端打启动日志（hermes desktop --help 无隐藏参数）。要静默需用 VBS ws.Run "cmd", 0, False 隐藏窗口方式拉起。若该应用你正在用、只是不想弹窗，倾向"保留自启但改隐藏 VBS"而非"关掉自启"。
3. ⚠️⚠️ VBS 隐藏对 console wrapper 无效（8/18 实测铁证）：.vbs 的 Run "...", 0 隐藏标志只作用于第一层进程。若目标是控制台启动器（如 venv 的 hermes.exe、python.exe），它内部 spawn python → uv python → 真正的 GUI exe 时，每一层子进程都会新建 conhost（黑窗）。实测启动链：hermes.exe desktop(27580) → python(27264) → uv python(25056) → Hermes.exe(28528)，每层一个控制台。改 VBS 隐藏 ≠ 问题解决——必须查完整子孙链（ParentProcessId 递归）确认启动链里有没有多层控制台程序。

• 判断方法：Get-CimInstance Win32_Process 递归查目标的 ParentProcessId 链，若含 ≥2 层 python/hermes 控制台程序 = VBS 隐藏无效。
• 正确修法：跳过 console wrapper，直接启动 GUI 版 exe（Electron 应用如 apps\desktop\release\win-unpacked\Hermes.exe，214MB 纯 GUI 程序无控制台）。行为等价（都会拉起 serve backend），但不经过多层 python。
• 验证：改完 VBS 后查 conhost 是否仍随启动新建——每个可见黑窗必有对应 conhost.exe（conhost=控制台窗口宿主）。启动后 conhost 数量不增 = 修复成功。

1. explorer 崩溃重启会重跑整个 Startup 文件夹（"两个一起闪"的隐藏机制）：explorer.exe 崩溃/被杀后重启，会重新执行 Startup 文件夹里的全部项（vbs/bat/lnk 全来一遍），造成"一批窗口同时弹"。8/18 实测：13:41:32 explorer 重启 → 13:41:32 那批 4 个 conhost 同时新建（hermes-desktop.vbs + memory-stack.vbs + napcat.vbs 同时触发）。判断方法：查 explorer 的 StartTime 是否很新 + 事件日志有 WER 崩溃上报：

``powershell # explorer 启动时间（新 = 刚重启过） powershell -NoProfile -Command "Get-Process -Name explorer | Select-Object Id,StartTime" # WER 崩溃上报（Application 日志 ProviderName='Windows Error Reporting'） powershell -NoProfile -Command "Get-WinEvent -FilterHashtable @{LogName='Application'; ProviderName='Windows Error Reporting'; StartTime=(Get-Date).AddHours(-2)} -MaxEvents 8 -ErrorAction SilentlyContinue | ForEach-Object { Write-Output ('[' + \$_.TimeCreated.ToString('HH:mm:ss') + '] ' + \$_.Message.Substring(0, [Math]::Min(200, \$_.Message.Length))) }" ``

• 根源链：显卡驱动崩溃（LiveKernelEvent 193 / BlueScreen 50，P3:10de=NVIDIA）→ 系统不稳 → explorer 崩 → Startup 重跑 → 弹窗爆发。本机有 5060/3070 eGPU，驱动崩溃是已知老毛病。
• 含义：就算所有 Startup 项都是隐藏 VBS，explorer 一崩还是会集体触发一次——所以"彻底无弹窗"还要保证每一项 vbs 本身真正隐藏（见坑位 10），而不是只删冗余。

1. gateway 反复被 SIGKILL 重启 = 弹窗重复源：gateway-exit-diag.log / gateway-starts.log 记录每次启动（epoch 时间戳）。若一天内 gateway.start 多次且每次 previous_unclean_exit，说明有 watchdog/启动点反复杀它重启，每次重启带 python 控制台窗口。查 gateway.log 的 lifecycle_ledger 行确认。

坑位（续·2026-08-19 追加：vbs 编码 + uv 假 pythonw + 验证自坑）