最稳妥的方式是直接在服务管理器（services.msc）中查看依赖关系：打开后右键目标服务→属性→“依存关系”选项卡，上半部分显示该服务所依赖的服务，下半部分显示依赖它的服务；带星号项为延迟或条件依赖，同样不可随意禁用。

直接在服务管理器里看依赖关系最稳妥，不用装工具也能避开“关一个、崩一串”的坑。

用服务管理器（services.msc）查依赖

这是最常用也最直观的方式：

• 按 Win + R 输入 services.msc 回车，打开服务列表
• 找到目标服务（比如 Netlogon 或 TermService），右键 → “属性”
• 切换到“依存关系”选项卡，这里分两块显示：
  • 上半部分是“此服务所依赖的服务”（它启动前必须先运行谁）
  • 下半部分是“依赖此服务的服务”（它停了，哪些服务会跟着出问题）
• 注意：有些依赖项带星号（*），表示是延迟加载或条件依赖，不是启动时硬性要求，但运行中调用到就会触发——也不能轻易关

用命令行快速查（适合批量或远程）

sc.exe 是系统自带的轻量工具，适合脚本或服务器无图形界面时使用：

• 查某服务的直接依赖：
  sc qc 服务名（例如 sc qc netlogon）→ 输出里找 DEPENDENCIES 行
• 查某服务被谁依赖（反向依赖）：
  sc enumdepend 服务名（例如 sc enumdepend rpcss）→ 列出所有依赖它的服务名
• 结果中的服务名是注册表里的短名（如 LanmanWorkstation），不是图形界面里看到的“工作站服务”，对应关系可在服务属性“常规”页看到

依赖链不能只看一层

一个服务依赖 A，A 又依赖 B，B 还依赖 C——这种多级链很常见。光看第一层容易误判：

windows-healing-gateway

通过任务计划程序自动监控并自修复 Windows 上的 OpenClaw Gateway，具备 AI 诊断和 Telegram 报警功能。

下载

• 比如停掉 NSI（Network Store Interface Service），可能让 Workstation 启动失败，进而导致 Netlogon 报错，最终域登录异常
• 建议对关键服务（如 RpcSs、DcomLaunch、LSASS）顺手查两层依赖，尤其留意是否牵扯到 SAMSS、LSA、EventLog 等核心组件
• 如果某服务的依赖列表里出现多个系统级服务，或者包含“MS_WindowsRemoteValidation”这类加载组，基本可以判定为不建议手动停止

注册表里也能验证（进阶参考）

所有依赖信息都存在注册表，路径统一：

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\服务名

• 查看 DependsOnService 值，类型是 REG_MULTI_SZ，内容就是它依赖的服务短名列表
• 这个值是系统启动时读取的依据，和 services.msc 显示一致，但修改需谨慎——写错会导致服务无法启动
• 日常排查不建议直接改注册表，仅用于确认或脚本读取