How to fix "NetAdapterCreate 0xC000000D" while creating a windows 11 WiFi Driver.

Hi @Sidharthan Srinivasan ,

Good to hear from you. Your recent update actually points toward what might be causing the STATUS_INVALID_PARAMETER (0xC000000D) error you encountered earlier.

Below is how your current setup seems to relate to the NetAdapterCx and WiFiCx integration:

The NetAdapterCreate Behavior: Since you mentioned that only the control path is developed, this is likely why your NetAdapterCreate call was failing. From what I’ve seen, NetAdapterCx generally expects data path callbacks (such as Tx and Rx queue creation) to be supplied before an adapter can be fully instantiated. Passing a NETADAPTER_INIT object without configuring the datapath via NetAdapterInitSetDatapathCallbacks often leads the framework to reject the setup with an Invalid Parameter error.

• Suggested Workaround: If you wish to proceed while your hardware data path is still under development, one approach is to implement "stub" (empty) versions of the EvtAdapterCreateTxQueue and EvtAdapterCreateRxQueue functions. Registering these dummy callbacks usually satisfies the framework's prerequisites smoothly, potentially allowing NetAdapterCreate to succeed so you can continue testing your control path.

WiFiCx vs. NetAdapterCx Integration: Regarding whether NetAdapterCx integration requires WiFiCx components, it is recommended to use them together. In Windows 11, a Wi-Fi driver typically shouldn't rely solely on NetAdapterCx.

• While NetAdapterCx serves as the foundation for passing network packets, WiFiCx acts as a specialized extension built on top of it.
• Integrating WiFiCx APIs alongside NetAdapterCx is considered standard practice, as the operating system usually expects to interact with your driver’s Wi-Fi control mechanisms (like scanning, WPA3, and OID handling) through this WiFiCx layer.

INF File Configuration: Finally, looking at your .INF file, it might be best to avoid exposing your driver as a generic Ethernet adapter.

• Ideally, your INF should define the device with Wi-Fi specific characteristics so the Windows WLAN service can categorize it properly. Usually, this means setting your device Class to Net and including the standard Wi-Fi NDIS keywords.
• If you are porting from an older WDI-based model, you might also want to note that vWifi functionalities are mostly retired. Removing any vWIFI related information from your INF and relying on the hardware characteristics (e.g., Characteristics = 0x84) is often the safest path.

A few resources that might provide more context on the integration and INF practices:

• Writing a WiFiCx client driver
• Introduction to Wi-Fi WDF class extension (WiFiCx)
• NetAdapterCx Overview
• Creating the Network INF File

If my explanation and the information I provided were helpful, I would greatly appreciate it if you could follow the instructions here so others with the same problem can benefit as well.

Thank you.

Sure Thanks Taki,

Will try and let you know my observations

Hi @Sidharthan Srinivasan ,

Please take your time to review and try it.

Looking forward to hearing from you soon!

Why i am asking is that currently our KMDF driver only has a data path, where i have created a small user mode application which is an .exe file where if i enter getversion. it will generate the required IOCTL to driver and driver will send required IOVAR to the chip. The response from the chip will be shown to the user in command prompt

My management is asking me to integrate netadaptercx first without wificx so that our KMDF driver could be visible to the windows networking stack. So apologize to ask the same question again. Is it possible to integrate netadaptercx alone without any inclusion of wificx because we still do not have event and data path in our KMDF driver.

let me know the possibilities. And also let me know if am missing anything. Also it would be much appreciated if you could share me the safest way to integrate netadpatercx to my current KMDF driver.

Let me know if my management's way of thinking is somehow wrong. If so let me know what exactly are they missing.

Hi @Sidharthan Srinivasan ,

Thanks for the clarification!

Regarding the possibility of integrating NetAdapterCx without WiFiCx, it seems doable to use NetAdapterCx on its own. If you take this route, Windows would typically see the device as a standard Ethernet (wired) adapter rather than a Wi-Fi card. This approach might be a safe way to ensure the OS network stack recognizes your driver before you introduce more complex Wi-Fi requirements (like scanning or WPA3). For an Ethernet-only approach, you would generally expose it as a basic network device in your .INF file, avoiding WDI/Native 802.11 specifics.

Looking closer at the 0xC000000D error you encountered, there appears to be a slight terminology overlap. The IOCTL functionality from your .exe is generally considered a Control/Management Path. In the context of Windows networking, the "Data Path" typically refers specifically to Tx/Rx network packet traffic (e.g., passing TCP/IP frames). It seems that NetAdapterCx generally rejects the NetAdapterCreate API (returning STATUS_INVALID_PARAMETER) if the framework isn't told how to handle these packet queues.

As for safe way to work around this and get the device to appear in the network stack without having the actual packet-passing logic ready, you might consider providing "dummy/stub" queues. Registering empty functions often satisfies the NetAdapterCx prerequisites. Below is a conceptual snippet that might help bypass the error:

// Create empty (stub) functions for Tx/Rx queues
NTSTATUS EvtMyAdapterCreateTxQueue(_In_ NETADAPTER Adapter, _Inout_ NETTXQUEUE_INIT *TxQueueInit) {
    // Return success temporarily
    return STATUS_SUCCESS; 
}
NTSTATUS EvtMyAdapterCreateRxQueue(_In_ NETADAPTER Adapter, _Inout_ NETRXQUEUE_INIT *RxQueueInit) {
    // Return success temporarily
    return STATUS_SUCCESS;
}
// Register them BEFORE calling NetAdapterCreate
NET_ADAPTER_DATAPATH_CALLBACKS datapathCallbacks;
NET_ADAPTER_DATAPATH_CALLBACKS_INIT(&datapathCallbacks, EvtMyAdapterCreateTxQueue, EvtMyAdapterCreateRxQueue);
NetAdapterInitSetDatapathCallbacks(AdapterInit, &datapathCallbacks);
// The creation step should now have a better chance of succeeding
status = NetAdapterCreate(AdapterInit, &adapterAttributes, &Adapter);

For more context on this approach, these resources might outline some helpful practices:

• NetAdapterCx Overview
• Device and adapter initialization
• NET_ADAPTER_DATAPATH_CALLBACKS_INIT function
• Creating network INF files

I hope this helps point you and your team in a helpful direction!

Thank you.

Hi Taki,

Thanks for the information.

My responses are getting auto deteted in the forum. I am unable to share my observations.

As we are bringing up a PCIe WLAN client driver using the official WiFiCx + NetAdapterCx model. We have removed the earlier standalone NetAdapterCx adapter-creation path and are now using the WiFiCx-owned adapter creation callback.

Current implemented sequence:

1. In EvtDriverDeviceAdd, we call:

NetDeviceInitConfig(DeviceInit);
WifiDeviceInitConfig(DeviceInit);
WdfDeviceCreate(...);
WIFI_DEVICE_CONFIG_INIT(...);
WifiDeviceInitialize(Device, &WifiDeviceConfig);

These calls succeed.

1. In EvtDevicePrepareHardware, we call the WiFiCx capability setters:

WifiDeviceSetDeviceCapabilities(...);
WifiDeviceSetBandCapabilities(...);
WifiDeviceSetPhyCapabilities(...);
WifiDeviceSetStationCapabilities(...);

All four return STATUS_SUCCESS.

1. WiFiCx then calls our adapter creation callback:

EvtWifiDeviceCreateAdapter(
    WDFDEVICE Device,
    NETADAPTER_INIT* AdapterInit
)

Inside this callback:

• AdapterInit is non-NULL.
• WifiAdapterInitGetType(AdapterInit) returns 1, which matches WIFI_ADAPTER_EXTENSIBLE_STATION.
• We register NetAdapterCx datapath callbacks:

NET_ADAPTER_DATAPATH_CALLBACKS_INIT(
    &DatapathCallbacks,
    EvtCreateTxQueue,
    EvtCreateRxQueue);

NetAdapterInitSetDatapathCallbacks(
    AdapterInit,
    &DatapathCallbacks);

• We register WiFiCx TX demux entries:

WIFI_ADAPTER_TX_PEER_ADDRESS_DEMUX_INIT(&PeerAddressDemux, 4);
WifiAdapterInitAddTxDemux(AdapterInit, &PeerAddressDemux);

WIFI_ADAPTER_TX_WMMINFO_DEMUX_INIT(&WmmInfoDemux);
WifiAdapterInitAddTxDemux(AdapterInit, &WmmInfoDemux);

• Then we call:

WDF_OBJECT_ATTRIBUTES_INIT_CONTEXT_TYPE(
    &AdapterAttributes,
    ADAPTER_CONTEXT);

status = NetAdapterCreate(
    AdapterInit,
    &AdapterAttributes,
    &NetAdapter);

1. Current blocking issue:

NetAdapterCreate() returns:

STATUS_INVALID_PARAMETER / 0xc000000d
NetAdapter = NULL

This happens after all of the above steps complete successfully.

1. We have not enabled the later stages yet:

WifiAdapterInitialize(NetAdapter);
NetAdapterStart(NetAdapter);

Those are intentionally gated off until NetAdapterCreate() succeeds.

1. Current INF / binding values:

Class = Net
Characteristics = 0x84

HKR, Ndi, *IfType, 0x00010001, 71
HKR, Ndi, *MediaType, 0x00010001, 16
HKR, Ndi, *PhysicalMediaType, 0x00010001, 9
HKR, Ndi, BusType, 0x00010001, 5

HKR, Ndi\Interfaces, UpperRange, 0, "ndis6"
HKR, Ndi\Interfaces, LowerRange, 0, "wlan"

Installed device class instance shows:

Class = Net
InfSection = IFX_PCIE.ndi.NT
*IfType = 71
*MediaType = 16
*PhysicalMediaType = 9
Characteristics = 132

Question:

Could you please confirm what additional WiFiCx/NetAdapterCx pre-NetAdapterCreate() requirement may be missing?

Specifically:

1. Is our sequence correct?

NetDeviceInitConfig
WifiDeviceInitConfig
WdfDeviceCreate
WifiDeviceInitialize
WifiDeviceSet*Capabilities
EvtWifiDeviceCreateAdapter
NetAdapterInitSetDatapathCallbacks
WifiAdapterInitAddTxDemux
NetAdapterCreate
WifiAdapterInitialize
NetAdapterStart

1. Are the INF values above valid for a WiFiCx extensible station driver?
2. Are there any required NETADAPTER_INIT or WiFiCx adapter-init APIs we must call before NetAdapterCreate()?
3. Does EvtWifiDeviceSendCommand need to be functional before NetAdapterCreate(), or only before WifiAdapterInitialize() / NetAdapterStart()?
4. Is there any framework diagnostic/verifier setting that can identify the exact invalid parameter causing NetAdapterCreate() to return 0xc000000d?We are bringing up a PCIe WLAN client driver using the official WiFiCx + NetAdapterCx model. We have removed the earlier standalone NetAdapterCx adapter-creation path and are now using the WiFiCx-owned adapter creation callback. Current implemented sequence:
   1. In EvtDriverDeviceAdd, we call:

      NetDeviceInitConfig(DeviceInit);
   

WifiDeviceInitConfig(DeviceInit); WdfDeviceCreate(...); WIFI_DEVICE_CONFIG_INIT(...); WifiDeviceInitialize(Device, &WifiDeviceConfig);

   
   These calls succeed.
   
   1. In `EvtDevicePrepareHardware`, we call the WiFiCx capability setters:
   
   ```haskell
   WifiDeviceSetDeviceCapabilities(...);
WifiDeviceSetBandCapabilities(...);
WifiDeviceSetPhyCapabilities(...);
WifiDeviceSetStationCapabilities(...);

All four return STATUS_SUCCESS.

1. WiFiCx then calls our adapter creation callback:

   EvtWifiDeviceCreateAdapter(
    WDFDEVICE Device,
    NETADAPTER_INIT* AdapterInit
)

Inside this callback:

• AdapterInit is non-NULL.
• WifiAdapterInitGetType(AdapterInit) returns 1, which matches WIFI_ADAPTER_EXTENSIBLE_STATION.
• We register NetAdapterCx datapath callbacks:

   NET_ADAPTER_DATAPATH_CALLBACKS_INIT(
    &DatapathCallbacks,
    EvtCreateTxQueue,
    EvtCreateRxQueue);

NetAdapterInitSetDatapathCallbacks(
    AdapterInit,
    &DatapathCallbacks);

• We register WiFiCx TX demux entries:

   WIFI_ADAPTER_TX_PEER_ADDRESS_DEMUX_INIT(&PeerAddressDemux, 4);
WifiAdapterInitAddTxDemux(AdapterInit, &PeerAddressDemux);

WIFI_ADAPTER_TX_WMMINFO_DEMUX_INIT(&WmmInfoDemux);
WifiAdapterInitAddTxDemux(AdapterInit, &WmmInfoDemux);

• Then we call:

   WDF_OBJECT_ATTRIBUTES_INIT_CONTEXT_TYPE(
    &AdapterAttributes,
    ADAPTER_CONTEXT);

status = NetAdapterCreate(
    AdapterInit,
    &AdapterAttributes,
    &NetAdapter);

1. Current blocking issue:

NetAdapterCreate() returns:

   STATUS_INVALID_PARAMETER / 0xc000000d
NetAdapter = NULL

This happens after all of the above steps complete successfully.

1. We have not enabled the later stages yet:

   WifiAdapterInitialize(NetAdapter);
NetAdapterStart(NetAdapter);

Those are intentionally gated off until NetAdapterCreate() succeeds.

1. Current INF / binding values:

   Class = Net
Characteristics = 0x84

HKR, Ndi, *IfType, 0x00010001, 71
HKR, Ndi, *MediaType, 0x00010001, 16
HKR, Ndi, *PhysicalMediaType, 0x00010001, 9
HKR, Ndi, BusType, 0x00010001, 5

HKR, Ndi\Interfaces, UpperRange, 0, "ndis6"
HKR, Ndi\Interfaces, LowerRange, 0, "wlan"

Installed device class instance shows:

   Class = Net
InfSection = IFX_PCIE.ndi.NT
*IfType = 71
*MediaType = 16
*PhysicalMediaType = 9
Characteristics = 132

Question:

Could you please confirm what additional WiFiCx/NetAdapterCx pre-NetAdapterCreate() requirement may be missing?

Specifically:

1. Is our sequence correct?

   NetDeviceInitConfig
WifiDeviceInitConfig
WdfDeviceCreate
WifiDeviceInitialize
WifiDeviceSet*Capabilities
EvtWifiDeviceCreateAdapter
NetAdapterInitSetDatapathCallbacks
WifiAdapterInitAddTxDemux
NetAdapterCreate
WifiAdapterInitialize
NetAdapterStart

1. Are the INF values above valid for a WiFiCx extensible station driver?
2. Are there any required NETADAPTER_INIT or WiFiCx adapter-init APIs we must call before NetAdapterCreate()?
3. Does EvtWifiDeviceSendCommand need to be functional before NetAdapterCreate(), or only before WifiAdapterInitialize() / NetAdapterStart()?
4. Is there any framework diagnostic/verifier setting that can identify the exact invalid parameter causing NetAdapterCreate() to return 0xc000000d?

Hi Taki,

Please find my response in the private conversation tab as my messages are getting auto deleted somehow in the forum. I do not know the reason. If there is any other way to reach out in better way please do let me know.

Thanks!!!