Well, sort of good and then bad news regarding the 7850 generic drivers.

I was able to track down similar issues with Code 37 due to needing a more up to date "Kernel-Mode Driver Framework" set on Windows 7, and tested both 32 and 64 bit after installing KB2685811. The good news is that it got further, and no longer yielded CM_PROB_FAILED_DRIVER_ENTRY (Code 37,) but now yields CM_PROB_FAILED_ADD (Code 31) meaning it cannot load the drivers at all (but did manage to call the entry point successfully.) Both have driver signature enforcement completely turned off, so that doesn't seem to be the issue. **Note that both of these error codes are different than what I get when I try to use the RTM versions of 8, 8.1, or 10.**

I also used dependency walker to check the drivers, and said everything they needed (both the xHCI and Hub) was present on the system. Only thing that stood out is that the actual linker version used for compiling/linking the .sys files was version 10, while Windows 7's usual version number is 9 (but this shouldn't matter unless I was trying to statically link the stuff myself, dynamic libraries should have independent interfaces for using them which should prevent this problem.)

I'm a bit frustrated, I get the feeling that they are close to working - but trying to diagnose Windows driver stuff in a black box fashion is so beyond my knowledge level.

Did some more research: yeah, sure enough, the 8 drivers with KB2685811 still result in Code 39, but the 7850 drivers definitely get further to this Code 31 stage. Maybe they are dependent on something in the registry that isn't created in the .inf? Or perhaps they reference something in the regular USB driver that was added in that 7 doesn't normally have? Wish I had some help here...

I have a Asus Z270 Apex with Intel USB 3.0 EXtensible Host Controller with Hardware Id's
PCI\VEN_8086&DEV_A2AF&SUBSYS_872F1043&REV_00
PCI\VEN_8086&DEV_A2AF&SUBSYS_872F1043
PCI\VEN_8086&DEV_A2AF&CC_0C0330
PCI\VEN_8086&DEV_A2AF&CC_0C03
Fernando,would your pure" 64bit Intel USB 3.0/3.1 Drivers v5.0.4.43 re-mod with DPInst option be the correct choice to install over the stock Microsoft drivers..

I tried a Samsung USB 3.1 dongle certified up to 200 Mb/sec writing, but I got only 25 Mb/sec on stock MS Win 10 drivers (Z170). Could the modded drivers help with speed?

Which is the right Driver for z390?

Fernando...thanks for all the work you have put in. I am new here so please excuse dumb questions.

Just read through you recent Intel USB 3.0/3.1 driver list and I don't see my Intel B360 chipset Hardware ID listed. The Hardware ID is not in your modded INF file either.

Is there an issue with this USB 3.1 Gen2 hardware?

From my Win 10 USB usbxhci.inf file for the mobo:

PCE\VEN_8086&DEV_A36D&SUBSYS_86941043&REV10

For compatible ID's, it lists:

-as above without the SUBSYS data, and:

&CC_0C0330 in place of DEV_A36D onward

-below is simplest compatible as PCI\CC_0C03

Thanks.

Fernando...here's the full list of dev hardware IDs and Compatible IDs for the Asus B360M-C/CSM USB controller as shown by Win 10 in dev manager.

Hardware IDs

PCI\VEN_8086&DEV_A36D&SUBSYS_86941043&REV_10
PCI\VEN_8086&DEV_A36D&SUBSYS_86941043
PCI\VEN_8086&DEV_A36D&CC_0C0330
PCI\VEN_8086&DEV_A36D&CC_0C03

Compatible IDs

PCI\VEN_8086&DEV_A36D&REV_10
PCI\VEN_8086&DEV_A36D
PCI\VEN_8086&CC_0C0330
PCI\VEN_8086&CC_0C03
PCI\VEN_8086
PCI\CC_0C0330
PCI\CC_0C03

Zitat von Jodec im Beitrag #1906

---

When searching for automatic driver updates or in a Windows Version Build Update the original-specific RENESAS driver is replaced with the MS generic one. Could you please make a modded version?

---

[quote=Mov AX, 0xDEAD|i tried win8 driver on win7 some time ago, matching import is not enough, ms usb3.x driver uses some implemenation of api on win8+.
so on win7 x32 i got kernelfault where all functions are exported from kernel/hal. i dont dig deeper[/quote]

My understand of this is limited at this point so don't take me seriously.

The drivers are called by setupapi.dll, called from the PnP manager. If Setupapi.dll in W7 tries to call a driver at an address in the driver that has been changed, you'll get a kernel fault. You'd really have to check where W10's setupapi is calling to see what address it wants in <driver>.sys.

HAL is the deepest layer for hardware interface and it should not be that much of an issue if you can get the kernel to read the driver via setupapp.dll. Then again, there are several layers to contend with as well.

I feel optimistic about this because I plugged a drive loaded with Win7 SP1 into an Asus B360M-C and it booted and ran fine after I got past the logon screen. That suggests to me that the W7 and W10 core are quite similar.

If all other drivers run with no problem on an 8th gen mobo then I don't see why USB 3 drivers cannot run.

I'm sure it's not that simple because there are likely several steps in-between. Just adding some thoughts to yours.

Zitat von Omicron im Beitrag #1936

---

Or perhaps they reference something in the regular USB driver that was added in that 7 doesn't normally have? Wish I had some help here...

---

Fernando...reading back to May 2018 you did try to add the B360 chipset (DEV_A36D) to your driver pack and it did not work. I would not mind having the modified driver pack if you still have it. I don't care if it doesn't work, I just want to play with it a bit.

I'll keep an eye out for updates from Intel and Asus. I know that Asus have released some drivers for certain devices.

Zitat von gordo999 im Beitrag #1947

---

Also, Process Monitor from Sysinternals, now Microsoft, can show you a detailed map of a process. You can see what files it was looking for, or reg entries, and which ones it could not find.
An old technique with a messed up system was to go into Device Manager and delete a pertinent section, or on some occasions, the entire tree in Device Manager. Windows would happily rebuild the entire tree.

---