利用process monitor 解决 无法启动的系统服务

上周 二，我接到了一个很诡异的案例，表现为任务栏右下角网络连接图标始终为一个红叉，已排除网卡硬件、链路和网卡驱动的问题。主板都新换了一块，可是问题依 旧，这无疑将问题的根源指向了操作系统。本想通过网络疑难解答包先自动排错，可是发现该疑难解答提示服务未能启动因此不能进行自动排错，经查 证，Diagnostic Policy Service 服务处于起不来的状态，报错"错误5：拒绝访问"。

 

经过我的排查，我发现系统的很多服务都未能启动，尤其是网络相关的很多服务，例如DHCP，防火墙，ICS，IPSec Policy Agent 等等。当我手动尝试启动这些服务时，除了有些报相关服务尚未启动之外，无一例外地，都报了一个错误——错误5：拒绝访问。（需要先启动的相关服务都是该错 误）

 

 

查看系统日志，将里面的更详细的错误代码拿去微软搜索，发现没有什么收获。在一些社区解决方案中，也没能找到行之有效的解决办法，甚至微软官方论坛有一个同样的案例，一个错误的/不太相关的解答被标记为正解……

 

这显然不是正解，我得找到一个解决该问题的办法。于是经过各种尝试，我最后通过 Process Monitor 的帮助，找到了服务无法启动的直接原因和解决办法。由于当时没有截图，所以今天我还原了一个当时的情景，以 Base Filtering Engine 服务的无法启动为例，阐述当时我的解决思路。Base Filtering Engine 服务简称 BFE，相关的网络安全服务（如 Windows 防火墙和 IPSec）依赖于它。

 

在打开 Process Monitor 的记录以后，我立即点击启动服务，来尝试启动 BFE。它立即报错"拒绝访问"，我同时也尝试启动了那些不能启动的服务，都成功地重现了问题。停止 ProcMon 的记录后，在已记录下的log中，我可以看见当该问题重现时系统各进程所做的一些操作。通过粗略的快速浏览翻查和关键字"denied"搜索，引起我注意 的是，很多注册表的访问遇到了 access denied 的错误。而在文件访问中，尚未发现该错误。为了精细地验证，我对当前记录下的log进行了筛选器的应用。

 

筛选条件	处理方式
Process Name = svchost.exe	包含
Result = ACCESS DENIED	排除

 

 

 

应用筛选后，我们可以看见所有相关的 Access Denied 的条目。当时真实环境里的可以看见很多这样的条目，因为很多服务都出现了无法启动的故障，而撰写本文时的实验环境里，我只制造了 BFE 这一种服务的该问题。通过 Path 列，我们可以看见其具体的路径为 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent . 右击该条目，选择 Jump To… ，注册表编辑器便会被调用打开打开，并且自动定位到该键。我查看其权限设置，发现所有条目继承于 Policy 键。

 

 

那我们就来看看该处的 Policy 键上的权限设置，与正常的计算机的同一位置的权限设置有何不同。

 

当前 Policy 键上的权限	正常 Policy 键上的权限

 

不难发现，服务不能启动（尤其是提示拒绝访问）的直接原因是因为，该服务无权访问注册表的这个键。（通过 Process Monitor 可以看出，它实际上要访问的是 Policy 的子键"Persistent"却遭到拒绝）

 

要尝试恢复，那我们要做的就是至少在 Persistent 键及其子键/键值上授予 BFE 合适的访问权限。为了一步到位，我做的是参照正常的系统，将正常的 ACE 项在权限传播的起始处——Policy 键上设置，并往下传播。设置时，除了还原应有的 BFE 的权限，还完全一致地将其他缺失权限补齐，将多余权限删除，这样可以避免一些额外的潜在问题。（例如权限仍过小或者过大）

 

值得注意的是，BFE 这个服务账号不同于一般用户账号和组，所以直接键入 BFE 时间查不到名称的。正确的做法是键入"NT Service\BFE"检查名称。

 

 

而默认地，BFE 在 BFE 服务的注册表项上的访问权限是特殊的。虽然我们可以直接授予完全控制权限来解决该问题，但是我们最好还是参照 LUA 原则，跟系统默认的一样，将其设为特殊权限。特殊权限的具体项目如下图所示：

 

 

好了，设置好并且应用权限之后，再次点击启动服务按钮，就可以看到该服务正常启动了。

 

最后，对于该诡异案例，有几个说明：

1. 究竟是什么操作导致了系统出现这样的问题，让诸多系统服务注册表键权限变成非默认值，至今尚不明确。据用户称，他就是出了个差，回来后就这样了，其间没有 装过什么软件或者手动做过这种设置注册表权限的危险操作。搜索互联网，很多人都有遇到此问题的经历，但是没有哪个帖子能够明确指出是什么操作引起了这个问 题。如果您恰好有过此方面的研究，欢迎告诉我。

2. 事实上，该用户最后重装系统了，这也是我建议他做的。因为，该问题的发生，可能还伴有其他的一些未知的系统严重性更改，修复了注册表权限，并且让服务启动后，不能确保他在该系统上，今后不会遇到其他的怪异问题。

3. 就像我遇到的这个真实案例一样，该错误一旦发生，往往会伴有很多系统服务遇到此拒绝访问的启动问题。如果要应用此方法全面修复，那是非常耗费时间和精力的。这里给出一个能尽量加速解决此问题的思路：

步骤	思路	优化的实现方法	备注
1	跟同一环境下的另一台健康计算机（公司加域情况、网络情况一致）做服务启动状态比较，定位出本机不正常的服务	用 PowerShell 执行 Get-Service,两份结果用 Excel 做比较	这步可以用查看系统服务日志找出未能启动的服务来替代（看从上次启动以后记录到的日志）
2	发现这些未能启动的服务背后相关联的权限不正常的注册表键	使用 Process Monitor 监控 Access Denied 的项目，注意合理应用筛选条件可以得到没有干扰的直接结果。得到结果后，将Path 栏的唯一值（注册表路径）整理成一份列表
3	获取正常系统上这些注册表位置的默认权限	通过 PowerShell 编写脚本，去 query 正常系统上这些对应的注册表键值的权限设置，并保存每一项对应的权限
4	将默认权限应用到问题计算机	通过 PowerShell 脚本，将上一步获取到的权限批量应用到问题计算机本地，实现定点修复。完毕后重启计算机，相关服务自然随着预设的"自动启动"类型重新启动

 

话说当年 NT 5.0 时代，可以通过系统自带的 secedit 命令重置所有安全设置和权限，但是现在已然不行了。鉴于目前尚未发现任何 fix 程序能够自动重置系统服务的默认注册表权限的，只能用以上4步进行修复。如果您所遇到的情形中只有一两项服务有此问题，那么完全可以不采用脚本的方式，而 是采用 GUI 的工具去看服务以及手动修复权限设置。等我今后有空的话，会写一个重置系统自带服务对应的注册表权限的脚本。（貌似意义不太大）若您有高见，请不吝赐教。