排查NDIS LWF驱动触发DPC_WATCHDOG_VIOLATION(133/1)蓝屏问题

针对你开发的NDIS LWF驱动在VPN连接时触发的133/1蓝屏问题，结合你提供的信息，以下是具体的排查方向：

1. 聚焦手动IRQL升降代码段的执行耗时 #

DPC_WATCHDOG_VIOLATION (133/1) 表示单个CPU核心上的DPC执行时间超过了系统看门狗阈值（通常约100ms）。你在调用NdisFIndicateReceiveNetBufferLists前后手动将IRQL提升至DISPATCH_LEVEL，该级别下系统无法进行线程调度，任何耗时操作都会直接触发超时。

• 检查该代码段内除NdisFIndicateReceiveNetBufferLists外的所有操作：是否存在内存拷贝、锁操作、或者其他自定义逻辑？这些操作在DISPATCH_LEVEL下的耗时可能被忽略。
• 使用调试命令 !stacks 2 DISPATCH_LEVEL 查看当前所有处于DISPATCH_LEVEL的调用栈，确认是否有与你的驱动相关的额外耗时路径。

2. 排查wanarp.sys自旋锁的持有情况 #

你怀疑wanarp的自旋锁关联问题，可通过以下方式验证：

• 执行调试命令 !locks 列出所有自旋锁，定位wanarp.sys所属的锁对象（通过锁地址的模块归属判断，用!address <lock-address>查看）。
• 对目标锁执行 !lock <lock-address>，查看锁的持有者线程、等待队列长度及持有时间。如果该锁在DISPATCH_LEVEL下被长时间持有，你的驱动在等待锁的过程中会耗尽看门狗时间窗口。

3. 分析资源竞争计数49135的关联性 #

若该计数来自!locks输出中的Contention Count，说明对应资源被高频竞争（近5万次），每次竞争的等待时间累积可能导致DPC超时：

• 找到该计数对应的锁地址，用!address确定所属模块：如果是你的驱动的锁，检查在DISPATCH_LEVEL下是否存在锁持有时间过长、锁粒度不合理的情况；如果属于wanarp.sys，则说明VPN路径中存在严重的锁竞争。
• 结合!spinlock命令分析锁的竞争频率和平均等待时间，判断是否是导致超时的直接原因。

4. 重新评估手动提升IRQL的必要性 #

你提到提升IRQL是为了规避另一已知问题，需重新验证该操作的合理性：

• 确认NdisFIndicateReceiveNetBufferLists的IRQL调用要求：NDIS规范中，LWF的接收指示可在PASSIVE_LEVEL或DISPATCH_LEVEL下执行，若原问题是IRQL不一致导致的，可考虑改用NdisScheduleWorkItem将接收指示移至工作线程（PASSIVE_LEVEL）执行，避免强制在不可抢占级别操作。
• 若必须在DISPATCH_LEVEL下执行，需尽可能压缩该级别下的代码逻辑，仅保留NdisFIndicateReceiveNetBufferLists调用本身，移除所有非必要操作。

5. 性能追踪与内核事件分析 #

使用Windows Performance Recorder (WPR) + Windows Performance Analyzer (WPA) 捕获并分析内核级事件：

• 启用NDIS、DPC/Interrupt、Spinlock相关的事件追踪，记录VPN连接时的系统行为。
• 在WPA中定位你的驱动提升IRQL的时间段，查看该时间段内的CPU占用、自旋锁等待时间、wanarp.sys的函数调用耗时，定位具体的瓶颈点。

6. 系统版本兼容性与补丁验证 #

目标系统为Windows 10 19041（2004版），需确认是否存在已知的wanarp或NDIS相关补丁：

• 查阅微软KB补丁列表，看是否有针对VPN场景下wanarp自旋锁超时、DPC看门狗误触发的修复补丁。
• 验证你的LWF驱动是否严格遵循NDIS 6.x规范，特别是接收指示的IRQL规则，避免因违规调用触发系统异常。

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