Windows 网络服务恢复：从错误码查到权限

2026 年 10 月 11 日，原生 Wi-Fi 无法正常使用，但 USB 共享网络还能临时联网。最后恢复网络的关键，是沿着服务依赖找到实际的拒绝访问，再根据证据修复局部注册表权限。

这是一份个案复盘。它解释排查方法，不提供可以套用到所有 Windows 电脑的批量改权限脚本。

先把“没有网络”拆成具体状态

最初的服务状态分成两组：

服务	当时结果
BFE、Dhcp、Dnscache	停止，启动时报错误 5
WinHttpAutoProxySvc、Wcmsvc、WlanSvc	停止，启动时报错误 1068
NSI、AFD、TCP/IP 及相关无线内核服务	检查时正在运行

微软的错误定义中，5 是拒绝访问；1068 表示依赖服务或依赖组启动失败。后者提示应该向上游追查，而不是把每个下游服务都当作独立故障。微软：错误码 0–499，错误码 1000–1299

在这台电脑当时的配置里，可以沿 DHCP/DNS、WinHTTP 自动代理、连接管理、WLAN 等依赖逐层核对。具体依赖来自本机配置，不能照搬成所有版本 Windows 的固定依赖图。

这一步也避免了过早卸载无线驱动：服务基础设施尚未正常运行时，即使换驱动，也未必能解决上层连接问题。保留 USB 备用联网则让后续查资料、备份和验证有了连续性。

错误 5 还不够，需要找到谁被拒绝

排查发现部分系统注册表键具有异常的受保护访问控制，服务需要的写入权限未能有效继承。已有父键上的允许项，并不意味着受保护子键一定获得相同权限。

这里使用 Microsoft Sysinternals 的 Process Monitor 做短时间定向捕获，把服务启动时刻、进程、运行身份、访问对象和请求权限放到一起比较。Procmon 能记录注册表、文件系统及进程/线程活动，并提供筛选与事件细节，适合用于这种关联取证。微软：Process Monitor

“出现过一次 ACCESS DENIED”仍不是充分结论。程序可能探测一个不允许的访问后走备用路径，因此还要核对失败是否对应服务启动、所需权限是否合理，以及系统组件清单中的安全基线。

修复范围为什么要小

实际处理按批次进行，只对证据支持的对象补充必要的服务身份访问项，并保留原所有者、组、拒绝项、其他访问项和保护状态。注册表安全描述符与请求的访问权限共同决定访问是否成功；粗暴扩大权限会改变这个安全边界。微软：注册表键安全与访问权限

这次没有把 Everyone 全控制作为通用答案，也没有递归重置整个系统注册表。权限最初为什么变成这样，现有记录没有证明，不能直接归咎某个软件或恶意程序。

防火墙服务的后续恢复又涉及另一批有边界的修复。由于并非每个启动阶段都有完整捕获，也不能回头从“这一批改完后成功”推导出某一个键就是唯一原因。

怎样确认网络确实恢复

第一阶段恢复后，BFE、DHCP、DNS、WinHTTP 自动代理、连接管理和 WLAN 服务运行，原生 Wi-Fi 可以连接。验证没有停在“图标亮了”，还检查了本机地址获取、网关连通、DNS 解析和实际网络访问，并保留备用联网配置。

随后防火墙服务及 IKEEXT 也恢复运行，目标服务状态正常，三个防火墙配置文件处于启用状态。它们是当时可以确认的成功结果。

验证顺序可以概括为：服务能启动 → 接口能连接 → 地址和路由合理 → DNS 能解析 → 实际应用能访问 → 防火墙仍启用。每层都留有对应时间的结果，才方便复发时比较。

没有被这次修复解决的部分

网络恢复后，后续组件修复时段仍出现服务宿主异常，后来又进行了系统重置和软件恢复。已有记录只支持时间先后，不能证明是组件修复或某项权限修改造成这些异常。

更重要的是，之后仍出现睡眠恢复、冷启动蓝屏和内存测试异常。网络恢复与整机稳定性属于两个结论：前者已有当时的功能验证，后者仍需要进一步排查。

这次经验最可复用的部分，是先确认依赖、再寻找拒绝访问、按证据缩小修改范围，并用真实功能验收。具体注册表权限应依据本机证据和可信基线处理，不能从一篇个案文章复制答案。