上周二，我接到了一个很诡异的案例，表现为任务栏右下角网络连接图标始终为一个红叉，已排除网卡硬件、链路和网卡驱动的问题。主板都新换了一块，可是问题依旧，这无疑将问题的根源指向了操作系统。本想通过网络疑难解答包先自动排错，可是发现该疑难解答提示服务未能启动因此不能进行自动排错，经查证，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 的工具去看服务以及手动修复权限设置。等我今后有空的话，会写一个重置系统自带服务对应的注册表权限的脚本。（貌似意义不太大）若您有高见，请不吝赐教。
本文转自 hbycscc 51CTO博客，原文链接:http://blog.51cto.com/mvperic/1128255