We are using DPDK to work with Intel X520-DA2 under Windows with netuio. After
adding its description to the INF file, we found that the driver fails to load:
netuio_map_hw_resources returns STATUS_DEVICE_CONFIGURATION_ERROR.

This adapter has the following resources (output from lspci -vvv in Linux):

01:00.0 Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+
Network Connection (rev 01)
...
    Region 0: Memory at c3800000 (64-bit, non-prefetchable) [size=512K]  
    Region 2: I/O ports at e020 [size=32]  
    Region 4: Memory at c3a00000 (64-bit, non-prefetchable) [size=16K]  
...

i/o port in Region 2 break the existing algorithm.

After modifying the code, the driver loaded successfully, and the adapter
started working as intended.

In the file netuio_dev.c — our modification of current code.

I’d like to clarify why such a complex algorithm was needed. Do you suspect
that WdfCmResourceListGetDescriptor might behave inconsistently across
different Windows versions?

   /*
    * ResourcesTranslated report MMIO BARs in the correct order, but their
    * indices differ from physical ones.

    * For example:
    * The values returned by WdfCmResourceListGetDescriptor can be condensed
like this:
    * Bar[0] = c840000c
    * Bar[1] = c800000c
    * Bar[2] = c844000c

    * But the BAR array has to be filled like this :
    * Bar[0] = c840000c
    * Bar[1] = null
    * Bar[2] = c800000c
    * Bar[3] = null
    * Bar[4] = c844000c
    * Bar[5] = null

Are you certain this is the case? Our tests don’t confirm this behavior. we see
        descriptor[0].Type = CmResourceTypeMemory
        descriptor[1].Type = CmResourceTypeDevicePrivate
        descriptor[2].Type = CmResourceTypeMemory
        descriptor[3].Type = CmResourceTypeDevicePrivate
        descriptor[4].Type = CmResourceTypeMemory
        descriptor[5].Type = CmResourceTypeDevicePrivate