|
问题：HONOR PC Manager 的 ProcessMonitor.sys WFP 驱动会错误拦截 IPv6 Loopback（::1），导致本机 localhost IPv6 连接失败 问题描述：
我的 Windows 电脑安装了 荣耀电脑管家。近期在使用依赖本机 OAuth 回调的应用时发现，浏览器访问 localhost 的 IPv6 回调地址会持续超时。进一步排查发现，并非应用本身或 Windows IPv6 配置异常，而是荣耀电脑管家安装的内核驱动： C:\Program Files\HONOR\PCManager\ProcessMonitor.sys 注册的 WFP（Windows Filtering Platform）Callout 会错误丢弃 IPv6 Loopback ::1 的流量。 环境信息： - Windows x64
- 已安装 HONOR PC Manager
- 相关内核服务名称：ProcessMonitor Service
- Driver Type：KERNEL_DRIVER
- Start Type：DEMAND_START
- Driver Path：C:\Program Files\HONOR\PCManager\ProcessMonitor.sys
可稳定复现的现象：
在 ProcessMonitor Service 正常运行时，执行：
ping 127.0.0.1
IPv4 Loopback 正常，4 个数据包全部成功。 但执行：
ping ::1
会立即得到：
一般故障一般故障一般故障一般故障
丢包率 100%。 同时 Windows 中 ::1 地址、::1/128 路由以及 IPv6 Loopback Interface 均正常存在，因此并不是 IPv6 地址或路由缺失。 实际业务影响：
我最初是在 ChatGPT/Codex 的 Remote Control OAuth 授权过程中发现该问题。ChatGPT.exe 会正常监听：
[::1]:1455
浏览器完成在线授权后需要回调：
http://localhost:1455/auth/callback
由于 localhost 解析到 ::1，浏览器无法连接本机已经处于 LISTENING 状态的服务，最终出现：
ERR_CONNECTION_TIMED_OUT
对 [::1]:1455 直接进行 TCP 连接测试也会超时。 因此该问题不仅影响 ping，也会导致所有依赖 IPv6 Loopback 的本机 TCP 服务存在连接失败风险。 已经进行过的排查：
我已经排除了普通 Windows 网络配置问题，包括： - IPv4 Loopback 127.0.0.1 正常；
- IPv6 地址 ::1 正常绑定到 Loopback Pseudo-Interface 1；
- ::1/128 路由正常；
- IPv6 协议绑定正常；
- 执行过 IPv6 reset、Winsock reset、TCP/IP reset 并重启，问题仍然存在；
- 停止/不启动 Tailscale、VPN/TUN 等网络工具后问题仍然存在。
WFP 抓包定位结果：
使用 Windows 官方 netsh wfp capture 对 ping ::1 进行捕获，发现 ICMPv6 Loopback 数据包：
IP version : IPv6Protocol : 58 (ICMPv6)Local : ::1Remote : ::1Loopback : true
被 WFP 明确分类为 DROP。 实际命中的规则为：
Filter ID : 135172Layer : FWPM_LAYER_INBOUND_TRANSPORT_V6Direction : INResult : CLASSIFY_DROP
对应的 WFP filter 为：
WfpFilterInboundTransportName
其 Action 为：
FWP_ACTION_CALLOUT_TERMINATING
对应 Callout：
WfpInboundTransportV6CalloutNameGUID:{2e498608-b3ef-4516-9c4d-e89b9f35e232}
该 filter 本身没有 filterCondition，即 IPv6 Inbound Transport 流量会进入该 terminating callout 进行处理。 进一步确认该 Callout 来自荣耀 ProcessMonitor.sys：
对：
C:\Program Files\HONOR\PCManager\ProcessMonitor.sys
进行只读二进制检查后，在驱动中直接找到了相同的 Callout GUID：
{2e498608-b3ef-4516-9c4d-e89b9f35e232}
二进制偏移：
0x22E18
并且以下 WFP 相关字符串也全部以 Unicode 字符串存在于该驱动内部：
WfpInboundTransportV6CalloutNameWfpAuthConncetV6CalloutNameWfpOnboundTransportV6CalloutNameWfpFilterInboundTransportNameWfpFilterAuthConnectV6NameWfpFilterOnboundTransportName
因此可以确认，该组 WFP Filter/Callout 是由荣耀电脑管家的 ProcessMonitor.sys 注册的。 最关键的 A/B 验证：
在问题存在时执行：
sc.exe stop ”ProcessMonitor Service”
驱动可以正常停止：
STATE : STOPPEDWIN32_EXIT_CODE : 0
在没有修改任何 IPv6 地址、路由、防火墙规则，也没有重启 Windows的情况下，立即再次执行：
ping ::1
结果立刻恢复正常：
来自 ::1 的回复: 时间<1ms来自 ::1 的回复: 时间<1ms来自 ::1 的回复: 时间<1ms来自 ::1 的回复: 时间<1ms已发送 = 4已接收 = 4丢失 = 0 (0% 丢失)
因此可以稳定复现：
ProcessMonitor.sys 运行 ↓::1 IPv6 Loopback 失败 ↓停止 ProcessMonitor Service ↓::1 IPv6 Loopback 立即恢复
结合 WFP Capture 中实际命中的 Filter ID、Callout GUID，以及该 GUID 和 Callout 名称均存在于 ProcessMonitor.sys 中，可以确认问题与荣耀电脑管家的该 WFP 驱动直接相关。 期望行为：
ProcessMonitor.sys 注册的 WFP Callout 不应拦截 Windows 本机 IPv6 Loopback 流量。至少对于：
::1 → ::1
的本机流量，应正确识别为 Loopback 并允许通过。 即使驱动需要对普通 IPv6 网络通信进行监控或过滤，也不应破坏 Windows IPv6 Loopback 的基本功能。 当前临时解决办法：
执行：
sc.exe stop ”ProcessMonitor Service”
可以立即恢复 ::1。 但由于该驱动属于荣耀电脑管家组件，长期手动停用可能影响电脑管家的部分监控、协同或其他功能，因此不适合作为正式解决方案。 希望官方协助：
请开发团队检查 ProcessMonitor.sys 中 IPv6 WFP Callout 对 Loopback 流量的 classify 逻辑，尤其是：
WfpInboundTransportV6CalloutName{2e498608-b3ef-4516-9c4d-e89b9f35e232}
对 ::1 流量的处理，并修复其错误 DROP IPv6 Loopback 的问题。 希望后续能够通过荣耀电脑管家或对应驱动更新提供修复版本。
| 
