如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 有效。 谁能告诉我我的进度有什么问题？非常感谢！
【问题讨论】：
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 团队）正在开发 NDIS 的继任者，名为 NetAdapter。 NDIS 和 NetAdapter 之间的主要架构区别在于 NetAdapter 不是一个单一的驱动程序框架，它不获取设备的所有权。相反，它是一个旨在与 WDF 干净交互的库，因此您所有常用的 WDF 功能都可以正常工作。但除非您从未来阅读此内容，否则 NetAdapter 可能尚未在您所针对的所有系统上可用。
【讨论】：
得知 WDF 不能直接与 NDIS 一起使用时，我有些惊讶（鉴于 WDF 已经存在很长时间了）。我被困在 PCIDRV 示例上，但今天我发现 https://github.com/Microsoft/NetAdapter-Cx-Driver-Samples 上提供了一个用于 WDF 的 NetAdapter 包装器（在 6 天后发布）。使用它，您可以使用框架和设备事件调用等。
【讨论】：