如https://technet.microsoft.com/en-us/windows/ff543720(v=vs.60)中所述 在调用DriverEntry之后，PnP管理器应调用NDIS的AddDevice例程。然后IRP_MN_START_DEVICE和MpInitializeEx计数... 在我的情况下，如果注册了MiniportDriver，则不会调用AddDevice（系统将在DriverEntry之后立即调用MpInitializeEx）。如果MiniportDriver未在DriverEntry中注册（仅调用WdfDriverCreate），则AddDevice起作用。 有人可以告诉我我的进度有什么问题吗？非常感谢！
答案 0 :(得分：0)
NDIS是一个整体驱动程序框架。它要求它拥有DEVICE_OBJECT以及与内核的任何交互。 WDF是另一个驱动程序框架，通常也需要相同的特权。他们不能同时拥有设备。只能由一个人来负责。
WDF确实支持“ miniport mode”，它禁用了其大部分功能，并允许您将WDF与NDIS一起使用。但是在这种模式下，您不会得到EvtWdfDriverDeviceAdd和大多数其他回调-NDIS拥有几乎所有内容的所有权，而WDF只是降级为少数辅助功能。
因此，要明确回答您的问题：如果DriverEntry调用NdisMRegisterMiniportDriver，除非设置了微型端口模式标志（WdfDriverCreate，否则不要调用WdfDriverInitNoDispatchOverride。并避免了大多数与设备相关的事件。您必须专门使用NDIS回调，例如MiniportInitializeEx来管理设备状态。这是NDIS体系结构的硬限制。
如果要将NIC驱动程序公开给Windows TCPIP堆栈，则必须使用NDIS。因此，这成为体系结构中不可协商的固定点。不可避免的结论是，除了WDF的微型端口模式之外，您不能在NIC驱动程序中使用WDF。
但是，有一个众所周知的解决方法。您可以让WDF管理您的设备，但不要告诉NDIS。而是枚举子设备并将该子设备交给NDIS。在某些情况下，这可能会带来一些不便（例如，您需要做一些额外的工作才能使NdisMRegisterInterrupt和RST正常工作），并且需要您了解NDIS和WDF并与之交互。但是这种结构已经附带了一些大众市场的NIC驱动程序，所以这并非没有可能。
顺便说一句，我们（Microsoft的NDIS团队）正在努力开发名为NetAdapter的NDIS的后继产品。 NDIS和NetAdapter之间的主要体系结构差异是NetAdapter不是单片驱动程序框架，并且不获取设备所有权。取而代之的是，该库旨在与WDF干净地接口，因此您所有常规WDF功能都可以正常工作。但是除非您以后再阅读，否则NetAdapter可能尚未在您定位的所有系统上提供。
答案 1 :(得分：0)
我很惊讶地知道WDF不能直接与NDIS一起使用（假设WDF已经存在很长时间了）。我被PCIDRV示例所困扰，但是今天我发现在https://github.com/Microsoft/NetAdapter-Cx-Driver-Samples（6天发布）上有一个适用于WDF的NetAdapter包装器。使用它，您可以使用框架和设备事件调用等。