Wow, ok, that was fun.

Hopefully somebody else can learn from my mistake here. Quick background... SDV uses your header files to determine your entry points. And you specifically have to declare them using the Function Roles Types, not the normal C prototype syntax. If you don't, SDV won't alert you to that error, but it will just hit any other errors that would come up as if you didn't have the function in your code at all. The entry points that SDV knows about get written into its SDV-map.h file that you can validate for correctness. This is publicly documented so I can't really complain too much.

But there's a big gotcha lurking here. I had my cleanup handler in the header file as:

EVT_WDF_OBJECT_CONTEXT_CLEANUP ObjectCleanup;

This was enough for me to verify that ObjectCleanup was present in the SDV-map.h file and move on to looking for other clues. What I didn't pick up on is that even though the callback member is declared like this:

PFN_WDF_OBJECT_CONTEXT_CLEANUP EvtCleanupCallback;

your function that you set to it must be declared like this:

EVT_WDF_DEVICE_CONTEXT_CLEANUP ObjectCleanup;

SDV apparently uses a text comparison and is not actually type aware.

So even though the two are equivalent:

typedef EVT_WDF_OBJECT_CONTEXT_CLEANUP EVT_WDF_DEVICE_CONTEXT_CLEANUP;

it seems you MUST use the one with "DEVICE" in the name.

The test passes now. Just to stick one last thumb in my eye it lists the result as "not applicable".

this memory range we used in slave side. But i don't know where it mapped in SBC side.

In ISA, the board claims its own address. The addresses aren't assigned by anyone else. In many cases, there was a set of DIP switches to select between several options. If you've used CC000 before, then that's probably it forever and ever.

My previous suggestion still stands. I suggest you write a non-PnP driver that unconditionally maps that address and see if you can access the card. That's going to be the least energy solution.

Look at the LogConfig directive of an INF file https://docs.microsoft.com/en-us/windows-hardware/drivers/install/inf-logconfig-directive This is how you make a non-PNP device's hardware known so it can be dealt with a driver written for PnP.

I'm not sure about your mathematics. A maximum bandwidth isochronous endpoint reserves 3072 x 8 bytes per frame, which is 24MB/s, about 40% of the bus. A certain percentage of the frame time is reserved for control and bulk endpoints, and you probably have USB HID devices (mice and keyboards) which have reservations for their interrupt endpoints. As a result, it's often impossible to select two max bandwidth interfaces. In Device Manager, if you can find your root port, there's a page that shows the current reservation percentage.

Do you have a custom driver? As far as I know, usbaudio.sys does not know how to handle endpoints with more than 1 transaction per microframe.

I am trying to write USB XHCI HOST and HUB driver over Kernel Mode Driver Framework ,
Challenge is to support as old as Windows XP/Server2003.
Where shall i start to implement the driver?

(Earlier thread on this topic here.) As of June 2, Microsoft has begun offering KB5014023 that solves the problem with DRIVER_VERIFIER_DMA_VIOLATION bugchecks when using external PCI devices with Kernel DMA Protection enabled. It is available as an optional update through Windows Updates for Windows 10 20H2 and above and should be part of the standard Patch Tuesday in the near future.

@gyroblau

The table in the documentation implies that a UMDF driver only gets read access to that key. https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/wdfdevice/nf-wdfdevice-wdfdeviceopenregistrykey

Think about how this could work. For most URLs, the first step is a DNS lookup to find the IP address. Then the browser will make a TCP connection to that host on the default or explicit port and try to establish some kind of HTTP connection. Most of the time that means TLS and HTTP 2.0, but there are many combinations and there are new ones being devised all the time.

The next question is exactly how the 'upload' is implemented by a specific website. You might think that it must be some kind of POST request, but there is a tremendous diversity in the way that this is implemented. And worse, it can change at any moment. And even if you can pin the exact sequence down, the TLS protocol is specifically designed to prevent surveillance or tampering.

And the final question is how exactly to identify the specific browser that you are trying to control. I can easily copy the binary for any browser to a new folder - and rename it too if I choose

Awesome follow-up. Thanks!