NDIS LWF驱动导致网络栈WFP异常及任务管理器进程网络使用率显示为0

任务管理器进程标签网络使用率为0的根因 #

任务管理器进程标签的进程级网络流量统计，依赖NDIS层在NBL（Net Buffer List）首次流转时绑定的进程归属标注：

• 发送方向：上层TCP/IP栈将NBL下发到NDIS栈时，会在NBL的元数据中标记该数据包所属的进程ID、对应套接字等关联信息，正常流程下NBL完成发送逐层回包完成时，TCP/IP栈会根据这些标记将流量计入对应进程的统计。你在LWF回调中直接提前调用NdisFSendNetBufferListComplete返还原始NBL，会让TCP/IP栈认为该NBL的发送流程已提前终止（被丢弃），不会触发对应进程的流量计数。而你后续下发的克隆NBL已经丢失了原始的进程关联元数据，无法被归属到任何进程，因此进程标签统计全部为0。
• 接收方向逻辑一致：你提前调用NdisFIndicateReceiveNetBufferLists上报原始NBL时，若你实际未将有效 payload 递交给上层，或是后续上报的克隆NBL无进程关联标记，同样不会被计入进程级统计。

性能标签与资源监视器统计正常的原因 #

• 任务管理器「性能>以太网」的统计是网卡硬件层面、NDIS微端口边缘的全局流量计数，只要数据包真实经过网卡收发就会被计数，和NBL的上层归属标记无关，因此统计准确。
• 资源监视器的流量统计直接读取TCP/IP栈内部的TCB（传输控制块）计数器、WFP流层统计数据，这些统计是在数据包最终被TCP/IP栈处理完成时更新的：你最终还是将合法数据包递交给了上下层协议栈，TCP/IP栈的内部连接统计会正常更新，因此资源监视器可以拿到真实的流量数据。你的猜测基本符合实际逻辑，两类工具的统计数据源确实存在层级差异。

对WFP驱动的影响 #

该操作确实会对WFP栈产生影响：

• WFP的多数过滤层位于TCP/IP栈与NDIS LWF之间，你后续下发/上报的克隆NBL不会再次经过上层WFP的过滤节点，会导致依赖WFP的防火墙规则、QoS策略、流量审计功能无法正常处理这部分克隆数据包。
• 你提前完成原始NBL的操作，会导致WFP的发送/接收完成层回调无法获取正确的数据包处理状态，可能触发部分WFP规则的误判或统计缺失。

修复建议 #

你可以调整LWF的数据包处理逻辑避免该问题：pend住原始NBL而非提前完成，克隆一份NBL用于和用户态交互做合法性判断，等用户态返回结果后，合法包直接走正常流程转发原始NBL，非法包再完成原始NBL并返回丢弃状态即可，原始NBL的所有元数据都会被保留，不会影响上层统计和WFP处理。

内容的提问来源于stack exchange，提问作者OneAndOnly