NetAdapterCx IPv4 interface failed to bind

NTDEV
1

I am writing a NetAdapterCx driver which encapsulates the packets over a non-ethernet link and running into a very strange issue. When I have the MediaType set to NdisMediumIP everything works great.

However I found out I need the Ethernet header so I am trying to change the MediaType to NdisMedium802_3. When I do that though I get the following error in Event Viewer:

The IPv4 TCP/IP interface with index 6 failed to bind to its provider.

This occurs on both Windows 10 and Windows 11. I am using WDK 10.0.22621.2428 (so almost newest).

When in this state the NIC shows up in Network Connections but does not show up when you run ipconfig. Trying to set the IP through the newer Control Panel in Windows 11 also comes back with an error.

My logs show that EvtAdapterCreateTxQueue and EvtAdapterCreateRxQueue execute just fine. I see EvtAdvance being called for my RxQueue and can even open the interface with Wireshark and see packets getting received. But EvtAdvance is never called for my TxQueue.

There is nothing unique about my INF setup:
Characteristics = 0x04 ; NCF_PHYSICAL
BusType = 5 ; PCIBus
*IfType = 6 ; IF_TYPE_ETHERNET_CSMACD
*MediaType = 0 ; NdisMedium802_3
*PhysicalMediaType = 14 ; NdisPhysicalMedium802_3
*IfConnectorPresent = 1 ; true
*ConnectionType = 1 ; NET_IF_CONNECTION_DEDICATED
*DirectionType = 0 ; NET_IF_DIRECTION_SENDRECEIVE
*AccessType = 2 ; NET_IF_ACCESS_BROADCAST
*HardwareLoopback = 0 ; false

There must be an API call I need to make when using NdisMedium802_3 that I am not making. I have no hardware offloads so I am not making any of those calls. I am setting a MAC address on the link so that is not it.

Anyone who can help me hunt this down it would be much appreciated because I am running out of ideas.

-Tom

2

Here's the raw event though I do not think it will help. Tried turning on driver verifier today with no success. Anyone have any idea how to debug this? How can I get more info out of Windows on why it is failing?

- <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
- <System>
  <Provider Name="Tcpip" /> 
  <EventID Qualifiers="49152">4207</EventID> 
  <Version>0</Version> 
  <Level>2</Level> 
  <Task>0</Task> 
  <Opcode>0</Opcode> 
  <Keywords>0x80000000000000</Keywords> 
  <TimeCreated SystemTime="2024-06-03T19:44:33.8318728Z" /> 
  <EventRecordID>7238</EventRecordID> 
  <Correlation /> 
  <Execution ProcessID="4" ThreadID="11784" /> 
  <Channel>System</Channel> 
  <Computer>xxyyzz</Computer> 
  <Security /> 
  </System>
- <EventData>
  <Data /> 
  <Data>IPv4</Data> 
  <Data>16</Data> 
  <Binary>0000000003003000000000006F1000C006000000BB0000C000000000000000000000000000000000</Binary> 
  </EventData>
  </Event>
3

I'll just post updates and hopefully someone will eventually stumble along with the answer. I got NDIS logging up and running through WinDbg. It looks like there is no good way to attach a giant log file though so going to try and grab a relevant snip.

I did two runs, once with MediaType 802.3 and once with IP using the values below (pretty sure I got them right). That was the only difference.

*MediaType              = 0     ; NdisMedium802_3
*MediaType              = 19    ; NdisMediumIP

When using NdisMediumIP TCPIP binds just fine and ndisBindNdis6Protocol returns a result of 0:

[1]0004.0164::06/04/2024-14:57:34.171 [sys]==> ndisBindNdis6Protocol: Miniport FFFFE00F10B5F030, Protocol FFFFE00F0A31EBB0
[1]0004.0164::06/04/2024-14:57:34.171 [sys]ndisReferenceProtocol[8]: Protocol: FFFFCB0C6642F390, RefCount: 4, Closing: 0
[1]0004.0164::06/04/2024-14:57:34.171 [sys]==> ndisIsMiniportStarted: Miniport FFFFE00F10B5F030
[1]0004.0164::06/04/2024-14:57:34.172 [sys]<== ndisIsMiniportStarted: Miniport FFFFE00F10B5F030, Started 1
[1]0004.0164::06/04/2024-14:57:34.172 [sys]>Begin protocol driver's BindAdapterHandlerEx. Protocol=FFFFE00F0A31EBB0
[1]0004.0164::06/04/2024-14:57:34.172 [sys]==> NdisOpenAdapterEx: Protocol FFFFE00F0A31EBB0: TCPIP is opening Adapter: \DEVICE\{965FF174-812A-4911-8645-8E3591E8C074}
[1]0004.0164::06/04/2024-14:57:34.172 [sys]ndisReferenceProtocol[9]: Protocol: FFFFCB0C6642F1E0, RefCount: 5, Closing: 0
[1]0004.0164::06/04/2024-14:57:34.173 [sys]==> ndisMOpenAdapter: Protocol FFFFE00F0A31EBB0, Miniport FFFFE00F10B5F030, Open FFFFE00F0E2BFA20
[1]0004.0164::06/04/2024-14:57:34.173 [sys]==> ndisSetupNdis6OpenHandlers: Protocol FFFFE00F0A31EBB0, Miniport FFFFE00F10B5F030, Open FFFFE00F0E2BFA20 bIsProt6 1, bIsMini6 1
[1]0004.0164::06/04/2024-14:57:34.173 [sys]==> ndisSetupMiniportProtocolHandlers: Protocol FFFFE00F0A31EBB0, Miniport FFFFE00F10B5F030, Open FFFFE00F0E2BFA20
[1]0004.0164::06/04/2024-14:57:34.173 [sys]<== ndisSetupMiniportProtocolHandlers: Protocol FFFFE00F0A31EBB0, Miniport FFFFE00F10B5F030, Open FFFFE00F0E2BFA20
[1]0004.0164::06/04/2024-14:57:34.173 [sys]==> ndisSetupLwfMiniportHandlers: Miniport FFFFE00F10B5F030
[1]0004.0164::06/04/2024-14:57:34.174 [sys]==> ndisSetupDownwardHandlers: Miniport FFFFE00F10B5F030
[1]0004.0164::06/04/2024-14:57:34.174 [sys]<== ndisSetupDownwardHandlers: Miniport FFFFE00F10B5F030
[1]0004.0164::06/04/2024-14:57:34.174 [sys]==> ndisSetupUpwardHandlers: Miniport FFFFE00F10B5F030
[1]0004.0164::06/04/2024-14:57:34.174 [sys]<== ndisSetupUpwardHandlers: Miniport FFFFE00F10B5F030
[1]0004.0164::06/04/2024-14:57:34.176 [sys]<== ndisSetupLwfMiniportHandlers: Miniport FFFFE00F10B5F030
[1]0004.0164::06/04/2024-14:57:34.176 [sys]<== ndisSetupNdis6OpenHandlers: Protocol FFFFE00F0A31EBB0, Miniport FFFFE00F10B5F030, Open FFFFE00F0E2BFA20
[1]0004.0164::06/04/2024-14:57:34.176 [sys]==> ndisQueueOpenOnMiniport: Miniport FFFFE00F10B5F030, Open FFFFE00F0E2BFA20
[1]0004.0164::06/04/2024-14:57:34.176 [sys]<== ndisQueueOpenOnMiniport: Miniport FFFFE00F10B5F030, Open FFFFE00F0E2BFA20, rc 1
[1]0004.0164::06/04/2024-14:57:34.176 [sys]==> ndisQueueOpenOnProtocol: Open FFFFE00F0E2BFA20, Protocol FFFFE00F0A31EBB0
[1]0004.0164::06/04/2024-14:57:34.177 [sys]<== ndisQueueOpenOnProtocol: Open FFFFE00F0E2BFA20, Protocol FFFFE00F0A31EBB0, rc 1
[1]0004.0164::06/04/2024-14:57:34.177 [sys]==> XSetupFrameTypeInFilter: Open FFFFE00F0E2BFA20
[1]0004.0164::06/04/2024-14:57:34.177 [sys]<== XSetupFrameTypeInFilter: Open FFFFE00F0E2BFA20
[1]0004.0164::06/04/2024-14:57:34.177 [sys]Open Adapter: Miniport FFFFE00F10B5F030, Open FFFFE00F0E2BFA20, TCPIP v6.40, XYZ Network Adapter 4-Port
[1]0004.0164::06/04/2024-14:57:34.177 [sys]<== ndisMOpenAdapter: Protocol FFFFE00F0A31EBB0, Miniport FFFFE00F10B5F030, Open FFFFE00F0E2BFA20, Status 0
[1]0004.0164::06/04/2024-14:57:34.178 [sys]NdisOpenAdapterEx: NewOpen FFFFE00F0E2BFA20, Protocol FFFFE00F0A31EBB0, Miniport FFFFE00F10B5F030
[1]0004.0164::06/04/2024-14:57:34.178 [sys]==>ndisMSwapOpenHandlers: Miniport FFFFE00F10B5F030, Flag 2
[1]0004.0164::06/04/2024-14:57:34.178 [sys]ndisUpdateMiniportFakeStatus: Miniport FFFFE00F10B5F030 now has XState 2 and FakeStatus c023001f
[1]0004.0164::06/04/2024-14:57:34.178 [sys]<==ndisMSwapOpenHandlers: Miniport FFFFE00F10B5F030
[1]0004.0164::06/04/2024-14:57:34.179 [sys]PktMonClientComponentRegister: Open=FFFFE00F0E2BFA20, Status=0xc00000a3(STATUS_DEVICE_NOT_READY)
[1]0004.0164::06/04/2024-14:57:34.179 [sys]<== NdisOpenAdapterEx: Protocol FFFFE00F0A31EBB0, Miniport FFFFE00F10B5F030, Open FFFFE00F0E2BFA20, Status 0
[3]0004.0164::06/04/2024-14:57:34.181 [sys]<End protocol driver's BindAdapterHandlerEx.   Protocol=FFFFE00F0A31EBB0, Status=0x00000000
[3]0004.0164::06/04/2024-14:57:34.182 [sys]==> ndisIndicateInitialStateToBinding: Open FFFFE00F0E2BFA20
[3]0004.0164::06/04/2024-14:57:34.182 [sys]<== ndisIndicateInitialStateToBinding: Open FFFFE00F0E2BFA20
[3]0004.0164::06/04/2024-14:57:34.182 [sys]==> ndisNotifyWmiBindUnbind: Miniport FFFFE00F10B5F030, Protocol FFFFE00F0A31EBB0, fBind 1
[3]0004.0164::06/04/2024-14:57:34.182 [sys]<== ndisNotifyWmiBindUnbind: Miniport FFFFE00F10B5F030, Protocol FFFFE00F0A31EBB0, fBind 1
[3]0004.0164::06/04/2024-14:57:34.183 [sys]ndisBindNdis6Protocol: Protocol: TCPIP, Adapter: XYZ Network Adapter 4-Port, Result: 0

But when using 802.3 to bind TCPIP ndisBindNdis6Protocol returns a result of c00000bb:

[3]0004.0168::06/04/2024-14:59:47.888 [sys]==> ndisBindNdis6Protocol: Miniport FFFFE00F10807030, Protocol FFFFE00F0A31EBB0
[3]0004.0168::06/04/2024-14:59:47.888 [sys]ndisReferenceProtocol[8]: Protocol: FFFFCB0C66437390, RefCount: 4, Closing: 0
[3]0004.0168::06/04/2024-14:59:47.888 [sys]==> ndisIsMiniportStarted: Miniport FFFFE00F10807030
[3]0004.0168::06/04/2024-14:59:47.889 [sys]<== ndisIsMiniportStarted: Miniport FFFFE00F10807030, Started 1
[3]0004.0168::06/04/2024-14:59:47.889 [sys]>Begin protocol driver's BindAdapterHandlerEx. Protocol=FFFFE00F0A31EBB0
[3]0004.0168::06/04/2024-14:59:47.889 [sys]==> NdisOpenAdapterEx: Protocol FFFFE00F0A31EBB0: TCPIP is opening Adapter: \DEVICE\{EC551D33-C8AF-47DA-8153-2351174F5D5B}
[3]0004.0168::06/04/2024-14:59:47.889 [sys]ndisReferenceProtocol[9]: Protocol: FFFFCB0C664371E0, RefCount: 5, Closing: 0
[3]0004.0168::06/04/2024-14:59:47.890 [sys]==> ndisMOpenAdapter: Protocol FFFFE00F0A31EBB0, Miniport FFFFE00F10807030, Open FFFFE00F0F34AA20
[3]0004.0168::06/04/2024-14:59:47.890 [sys]==> ndisSetupNdis6OpenHandlers: Protocol FFFFE00F0A31EBB0, Miniport FFFFE00F10807030, Open FFFFE00F0F34AA20 bIsProt6 1, bIsMini6 1
[3]0004.0168::06/04/2024-14:59:47.890 [sys]==> ndisSetupMiniportProtocolHandlers: Protocol FFFFE00F0A31EBB0, Miniport FFFFE00F10807030, Open FFFFE00F0F34AA20
[3]0004.0168::06/04/2024-14:59:47.890 [sys]<== ndisSetupMiniportProtocolHandlers: Protocol FFFFE00F0A31EBB0, Miniport FFFFE00F10807030, Open FFFFE00F0F34AA20
[3]0004.0168::06/04/2024-14:59:47.891 [sys]==> ndisSetupLwfMiniportHandlers: Miniport FFFFE00F10807030
[3]0004.0168::06/04/2024-14:59:47.891 [sys]==> ndisSetupDownwardHandlers: Miniport FFFFE00F10807030
[3]0004.0168::06/04/2024-14:59:47.891 [sys]<== ndisSetupDownwardHandlers: Miniport FFFFE00F10807030
[3]0004.0168::06/04/2024-14:59:47.891 [sys]==> ndisSetupUpwardHandlers: Miniport FFFFE00F10807030
[3]0004.0168::06/04/2024-14:59:47.892 [sys]<== ndisSetupUpwardHandlers: Miniport FFFFE00F10807030
[3]0004.0168::06/04/2024-14:59:47.892 [sys]<== ndisSetupLwfMiniportHandlers: Miniport FFFFE00F10807030
[3]0004.0168::06/04/2024-14:59:47.892 [sys]<== ndisSetupNdis6OpenHandlers: Protocol FFFFE00F0A31EBB0, Miniport FFFFE00F10807030, Open FFFFE00F0F34AA20
[3]0004.0168::06/04/2024-14:59:47.901 [sys]==> ndisQueueOpenOnMiniport: Miniport FFFFE00F10807030, Open FFFFE00F0F34AA20
[3]0004.0168::06/04/2024-14:59:47.901 [sys]<== ndisQueueOpenOnMiniport: Miniport FFFFE00F10807030, Open FFFFE00F0F34AA20, rc 1
[3]0004.0168::06/04/2024-14:59:47.902 [sys]==> ndisQueueOpenOnProtocol: Open FFFFE00F0F34AA20, Protocol FFFFE00F0A31EBB0
[3]0004.0168::06/04/2024-14:59:47.902 [sys]<== ndisQueueOpenOnProtocol: Open FFFFE00F0F34AA20, Protocol FFFFE00F0A31EBB0, rc 1
[3]0004.0168::06/04/2024-14:59:47.902 [sys]==> XSetupFrameTypeInFilter: Open FFFFE00F0F34AA20
[3]0004.0168::06/04/2024-14:59:47.902 [sys]<== XSetupFrameTypeInFilter: Open FFFFE00F0F34AA20
[3]0004.0168::06/04/2024-14:59:47.902 [sys]Open Adapter: Miniport FFFFE00F10807030, Open FFFFE00F0F34AA20, TCPIP v6.40, XYZ Network Adapter 4-Port
[3]0004.0168::06/04/2024-14:59:47.903 [sys]<== ndisMOpenAdapter: Protocol FFFFE00F0A31EBB0, Miniport FFFFE00F10807030, Open FFFFE00F0F34AA20, Status 0
[3]0004.0168::06/04/2024-14:59:47.903 [sys]NdisOpenAdapterEx: NewOpen FFFFE00F0F34AA20, Protocol FFFFE00F0A31EBB0, Miniport FFFFE00F10807030
[3]0004.0168::06/04/2024-14:59:47.903 [sys]PktMonClientComponentRegister: Open=FFFFE00F0F34AA20, Status=0xc00000a3(STATUS_DEVICE_NOT_READY)
[3]0004.0168::06/04/2024-14:59:47.903 [sys]<== NdisOpenAdapterEx: Protocol FFFFE00F0A31EBB0, Miniport FFFFE00F10807030, Open FFFFE00F0F34AA20, Status 0
[3]0004.0168::06/04/2024-14:59:47.904 [sys]==> NdisCloseAdapterEx: Open FFFFE00F0F34AA20
[3]0004.0168::06/04/2024-14:59:47.904 [sys]==> NdisCloseAdapter: Open FFFFE00F0F34AA20
[3]0004.0168::06/04/2024-14:59:47.904 [sys]Close Adapter: Miniport FFFFE00F10807030, Open FFFFE00F0F34AA20, TCPIP, XYZ Network Adapter 4-Port
[3]0004.0168::06/04/2024-14:59:47.904 [sys]==> ndisCleanUpForProtocol: Open FFFFE00F0F34AA20
[3]0004.0168::06/04/2024-14:59:47.905 [sys]<== ndisCleanUpForProtocol: Open FFFFE00F0F34AA20
[3]0004.0168::06/04/2024-14:59:47.905 [sys]==> ndisMKillOpen: Open FFFFE00F0F34AA20
[3]0004.0168::06/04/2024-14:59:47.905 [sys]==> ndisMFinishClose: MOpen FFFFE00F0F34AA20
[3]0004.0168::06/04/2024-14:59:47.905 [sys]==> ndisDeQueueOpenOnProtocol: Open FFFFE00F0F34AA20, Protocol FFFFE00F0A31EBB0
[3]0004.0168::06/04/2024-14:59:47.906 [sys]<== ndisDeQueueOpenOnProtocol: Open FFFFE00F0F34AA20, Protocol FFFFE00F0A31EBB0
[3]0004.0168::06/04/2024-14:59:47.915 [sys]==> ndisDeQueueOpenOnMiniport: Open FFFFE00F0F34AA20, Miniport FFFFE00F10807030
[3]0004.0168::06/04/2024-14:59:47.915 [sys]==> ndisUnsetNdis6OpenHandlers: Miniport FFFFE00F10807030
[3]0004.0168::06/04/2024-14:59:47.915 [sys]==> ndisUnsetNdis6OpenHandlers: Miniport FFFFE00F10807030
[3]0004.0168::06/04/2024-14:59:47.915 [sys]<== ndisDeQueueOpenOnMiniport: Open FFFFE00F0F34AA20, Miniport FFFFE00F10807030
[2]0004.0180::06/04/2024-14:59:47.916 [sys]==> ndisMQueuedFinishClose: Open FFFFE00F0F34AA20, Miniport FFFFE00F10807030
[2]0004.0180::06/04/2024-14:59:47.916 [sys]>Begin protocol driver's CloseAdapterCompleteHandlerEx. Protocol=FFFFE00F0A31EBB0, Open=FFFFE00F0F34AA20
[2]0004.0180::06/04/2024-14:59:47.916 [sys]<End protocol driver's CloseAdapterCompleteHandlerEx.   Protocol=FFFFE00F0A31EBB0, Open=FFFFE00F0F34AA20
[3]0004.0168::06/04/2024-14:59:47.916 [sys]<== ndisMFinishClose: Mopen FFFFE00F0F34AA20
[2]0004.0180::06/04/2024-14:59:47.916 [sys]==> ndisNotifyWmiBindUnbind: Miniport FFFFE00F10807030, Protocol FFFFE00F0A31EBB0, fBind 0
[3]0004.0168::06/04/2024-14:59:47.917 [sys]<== ndisMKillOpen: Open FFFFE00F0F34AA20
[2]0004.0180::06/04/2024-14:59:47.917 [sys]<== ndisNotifyWmiBindUnbind: Miniport FFFFE00F10807030, Protocol FFFFE00F0A31EBB0, fBind 0
[2]0004.0180::06/04/2024-14:59:47.917 [sys]==>ndisDereferenceProtocol[9]: Protocol FFFFE00F0A31EBB0,  RefCount: 4
[3]0004.0168::06/04/2024-14:59:47.917 [sys]==> NdisCloseAdapter: Open FFFFE00F0F34AA20, Status 103
[2]0004.0180::06/04/2024-14:59:47.917 [sys]<== ndisDereferenceProtocol: Protocol FFFFE00F0A31EBB0
[2]0004.0180::06/04/2024-14:59:47.918 [sys]==> ndisRemoveOpenFromGlobalList: Open FFFFE00F0F34AA20
[2]0004.0180::06/04/2024-14:59:47.918 [sys]<== ndisRemoveOpenFromGlobalList: Open FFFFE00F0F34AA20
[3]0004.0168::06/04/2024-14:59:47.918 [sys]==> NdisCloseAdapterEx: Open FFFFE00F0F34AA20, Status 103
[2]0004.0180::06/04/2024-14:59:47.919 [sys]<== ndisMQueuedFinishClose: Open FFFFE00F0F34AA20, Miniport FFFFE00F10807030
[3]0004.0168::06/04/2024-14:59:47.919 [sys]<End protocol driver's BindAdapterHandlerEx.   Protocol=FFFFE00F0A31EBB0, Status=0xc00000bb
[3]0004.0168::06/04/2024-14:59:47.919 [sys]ndisBindNdis6Protocol: Protocol: TCPIP, Adapter: XYZ Network Adapter 4-Port, Result: c00000bb

In both cases the UpperRange is set to "ndis5", I have also tried "ndis5_ip" with no success.

HKR, Ndi\Interfaces,    UpperRange, 0, "ndis5"
HKR, Ndi\Interfaces,    LowerRange, 0, "ethernet"
4

You are the first non-MSFT person I’ve encountered who’s using this relatively new Class Extension. I’m super curious to see how it works out. Having said that, be prepared for a few problems along the way… if not in the Class Extension itself, the with the (lack of) documentation.

Please DO continue to post about your experiences. Those can only be helpful for those who come after you.

5

@Peter_Viscarola_OSR overall I have been happy with it. I have a very short time to produce this driver and while I know plenty about using WDF to write drivers for PCIe FPGAs I know nothing about NDIS. So NetAdapterCx seemed like a logical choice. The documentation is decent though when I have time I will probably submit a pull request for some items that could be more clear.

I think for my next troubleshooting step I am going to go ahead and tell NetAdapterCx I have checksum offloads and see what happens. I can always just flag everything as valid.

Also I was thinking about posting a barebones driver to GitHub that demonstrates the problem. I think I could make a driver that would bind to any PCIe device and skip all the normal stuff you would do in Prepare Hardware but still instantiate the NetAdapterCx. Once I have that done though I am not sure how to get someone at Microsoft to look at it.

6

That’s very community-minded of you. Bravo, and thanks!

If you post your example to GitHub, I can ask friends on the WDK team to have a look, and (hopefully) get the NetAdapterCx folks to review it.

No guarantees, of course, it at least we can ask, right?

7

@Peter_Viscarola_OSR I tried some more random settings and am at a loss here. Hopefully someone at Microsoft will help. Here is the sample project that demonstrates the issue:

I am crossing my fingers it can be solved (or worked around) with a code change on my end as I need to have this working by the end of the month. Thanks for the help.

-Tom

8

@Peter_Viscarola_OSR I'm overdue to circle back on this.

I did get a hold of the NetAdapter team by e-mailing NetAdapter@microsoft.com (from the GitHub page).

They promptly responded that I had to call NetAdapterSetReceiveFilterCapabilities for an Ethernet driver. Sure enough this solved the issue... on Windows 11.

For Windows 10 I noticed that in the initial 2.0 release in WDK 10.0.19041.0 there was a "preview" version that had API calls NetAdapterSetPacketFilterCapabilities and NetAdapterSetMulticastCapabilities which seemed to serve the same purpose so I asked about those APIs and Windows 10 support.

The response I got was that those were merged into NetAdapterSetReceiveFilterCapabilities. The individual responding to me did not believe there was any way to support Ethernet in NetAdapter 2.0 and that only Mobile Broadband was supported (which is not what the documentation says). They said they would get back to me with a definitive answer.

Never got an answer. I sent two more e-mails. Still no answer.

I did rebuild my driver against the preview version and so far it is working just fine on Windows 10. My customer will only be using the driver on a handful of Windows 10 PCs and eventually those PCs are going to be upgraded to Windows 11. So for now I am going to take a chance on the preview version.

It is disappointing that I never got an answer from Microsoft when they said they would get back to me. I plan on opening a pull request shortly to correct the NetAdapterCx version documentation. Will be interested to see how that gets handled when I submit it.

-Tom

9

A NetAdapterCx Ethernet driver can't be made for both Windows 10 and 11 because the NetAdapterCx 2.0 preview version is required to run it on Windows 10. However, a driver built with the preview version will not load on Windows 11 because the WDF class extension will not bind.

You must compile one driver for Windows 10 using the preview version and a separate one for Windows 11 with a higher version. This requires ugly compile-time switches due to API changes related to Multicast and Filter Capabilities. If you remove those functions to make it compatible with NetAdapterCx 2.0 for both Windows 10 and 11, you will end up with a defective Ethernet driver that can't be configured with an IP address, among other issues.

10

That is precisely what I ended up doing. I created two separate project files:

  • Windows 10:
    Visual Studio 2019
    WDK 10.0.19041
    NetAdapter v2.0

  • Windows 11:
    Visual Studio 2022
    WDK 10.0.22621
    NetAdapter v2.2

In my PrepareHardware callback when _NETADAPTER_2_0_H_ is not defined I call NetAdapterSetReceiveFilterCapabilities. When it is defined I call the preview API functions NetAdapterSetPacketFilterCapabilities and NetAdapterSetMulticastCapabilities.

The compile-time switches are certainly undesirable but not that ugly. Especially when compared to the only other option being to rewrite as a WDM / NDIS 6.x driver.

1 Like