As descriped in https://technet.microsoft.com/en-us/windows/ff543720(v=vs.60) PnP manager should call NDIS's AddDevice routine after DriverEntry is called. And then IRP_MN_START_DEVICE and MpInitializeEx countinues ... On my situation, AddDevice is not called if MiniportDriver is registered(the system will call MpInitializeEx immediately after DriverEntry). If MiniportDriver is not registered in DriverEntry(Only WdfDriverCreate is called), AddDevice works. Anyone can tell me what's wrong with my progress? Thanks a lot!
NDIS is a monolithic driver framework. It demands that it owns the DEVICE_OBJECT and any interaction with the kernel. WDF is another driver framework, which typically also demands the same privileges. They cannot both own the device; only one can be in charge.
WDF does support a "miniport mode" where it disables most of its functionality and allows you to use WDF with NDIS. But in this mode, you don't get EvtWdfDriverDeviceAdd and most other callbacks -- NDIS takes ownership of almost everything, and WDF is just relegated to a handful of helper functions.
So, to explicitly answer your question: if your DriverEntry calls NdisMRegisterMiniportDriver it must not call WdfDriverCreate unless it sets the miniport mode flag (WdfDriverInitNoDispatchOverride) and avoids most of the device-related Evts. You must exclusively use NDIS callbacks, like MiniportInitializeEx, to manage device state. This is a hard limitation of the NDIS architecture.
If you want to expose a NIC driver to the Windows TCPIP stack, you must use NDIS. So that becomes a non-negotiable fixed point in your architecture. The inescapable conclusion is that you can't use WDF in a NIC driver, except WDF's miniport mode.
However, there is a well-known workaround. You can have WDF manage your device, but don't tell NDIS about it. Instead, enumerate a child device and give that child device to NDIS. This can be somewhat inconvenient in some cases (e.g., you would need to do extra work to make NdisMRegisterInterrupt and RST work) and requires you to understand and interface with both NDIS and WDF. But several mass-market NIC drivers have shipped with this architecture, so it's not impossible.
Incidentally, we (the NDIS team at Microsoft) are working on a successor to NDIS, named NetAdapter. The key architectural difference between NDIS and NetAdapter is that NetAdapter is not a monolithic driver framework, and it does not take ownership of the device. Instead, it's library that is designed to cleanly interface with WDF, so all your usual WDF features work normally. But unless you're reading this from the future, NetAdapter is probably not yet available on all the systems you're targeting.