我正在开发一个NDIS 6微型端口虚拟网卡驱动程序，它不处理IRP_MJ_POWER或IRP_MN_SET_POWER。驱动程序不在IRP_MJ_POWER的DispatchPower函数中注册。它将此设置为NULL。驱动程序使用OID_PNP_CAPABILITIES和OID_PNP_SET_POWER进行电源管理。
最近，我在Windows 7计算机上观察到代码为DRIVER_POWER_STATE_FAILURE（9f）的崩溃。在做了一些分析之后，我发现崩溃的发生是因为驱动程序没有处理Power IRP（IRP_MJ_POWER）超过10分钟。这是我第一次发现这个问题。
我也很想知道更多关于向驾驶员交付IRP_MJ_POWER / IRP_MN_SET_POWER的信息。 NDIS驱动程序是否必须处理这些IRP。我见过多个没有为IRP_MJ_POWER注册的调度功能的微型端口驱动程序。如果它不是强制性的并且驱动程序不需要为IRP_MJ_POWER注册调度功能，那么在什么条件下就会发生这样的问题。
答案 0 :(得分：2)
NDIS微型端口不能（也不能）直接处理IRP。 NDIS代表微型端口处理它们。通常，当您看到系统显示某些WDM行为（如讨论IRP的错误检查）时，您需要在心理上将其转换为等效的NDIS概念和回调。不幸的是，这一开始并不总是显而易见的 - 需要花费几年时间与NDIS合作才能掌握这一点。
在9F的特定情况下 - 这是网络适配器的非常常见错误检查。它大约有70％的时间是因为微型端口驱动程序泄漏了NET_BUFFER_LIST并且没有将NBL完成回NDIS。这是一个常见的代码错误，因为否则没有泄漏NBL的症状，并且它们都忽略了一个小漏洞。
大约20％的时间，网络中的9F是由于其他一些东西被卡住引起的，比如在OppidPause中卡住的OID或死锁。网络9F的剩余百分之几是由过滤器驱动程序中的错误（也容易泄漏NBL）和偶尔的操作系统错误引起的。
在网络驱动程序中调试9F时，您应该集中注意力（1）确定哪些内容没有完成（NBL，OID，函数调用等），然后（2）找出为什么没有完成。有时你很幸运，内核调试器命令!stacks 2 ndis!让所有堆栈都处于一个整齐的小死锁中，让你解开。其他时候你需要添加一些诊断/计数器来缩小NBLs的发生范围。