They do not provide drivers)))
mod is simple, but need switch windows to testsigning mode, and many users do not like textmessages about it on desktopâŚ
It is the task of the chipset manufacturers (here: Intel) to compile the required drivers for their on-board Controllers and to send them to the OEMs (= PC/mainboard manufacturers) and it is the task of the OEMs (here: Lenovo) to offer these drivers drivers for their customers.
@Fernando :
Done,works like a charm.Thank you again.
Edit by Fernando: Unneeded fully quoted post replaced by directly addressing (to save space and for better readability)
Canât you do another mod to remove âtestsigningâ mode from desktop? I know you used to be able to do that
@Mov_AX_0xDEAD :
If you would modify the SYS file, I can try to give the modified driver a valid digital signature.
Maybe the problem can be temporarily solved this way.
mod is simple, but need switch windows to testsigning mode, and many users do not like textmessages about it on desktopâŚ
I thought, there is NO driver at all for Z390 USB 3.0/3.1-Controller (except a generic driver already integrated in W10) whatsoever - how can you mod something that does not exist?
AZ
The related Intel USB 3.0/3.1 drivers exist, but they do not work with Z390 Chipset systems, because the related DeviceID is blocked by Intelâs code of the *.SYS file.
Hold up a minute, are you actually saying that code to handle âDEV_A36Dâ specifically is inside of the drivers provided by Intel? Like there is a simple switch in there blocking it inside of 5.0.4.43 in something like iusb3xhc.sys (or the hub/switch driver?)
Thatâs ridiculously big if true.
Hold up a minute, are you actually saying that code to handle "DEV_A36D" specifically is inside of the drivers provided by Intel? Like there is a simple switch in there blocking it inside of 5.0.4.43 in something like iusb3xhc.sys (or the hub/switch driver?)
code inside iusb3xhc.sys check for dev_id and compare with "know" codes (virtual list of usb3.0 and usb3.1 dev_ids, see .inf)
if check passed, driver assign some internal "magic" type to device (dev_id 8C7F=>20, dev_id A12F=>75 and etc) and set some abilities based on type (container of bits)
if check failed, driver unload wit error
driver unload with error
@ all Win7 x64 users with a DEV_A36D Intel USB 3.1 Controller:
Recently I have asked our Forum member Mov AX, 0xDEAD, whether he would be willing to modifify the 64bit SYS file of the latest Intel USB 3.0/3.1 Controller driver to make it usable with DEV_A36D Controllers, and he gratefully promised to do it in January 2019.As soon as I have gotten the SYS file, I will offer a freshly customized mod+signed 64bit Intel USB 3.0+3.1 driverpack v5.0.4.43 for DEV_A36D Controllers.
EDIT: Meanwhile Mov AX, 0xDEAD has withdrawn his promise (due to the Copyright rules regarding Intelâs driver code). So nobody should expect from my side any Intel USB 3.0/3.1 driver (= *.SYS file), whose code had been modified to make it usable with the DEV_A36D Controller while running Win7. I am sorry about that.
Windows 10 (as well as 8.1 and 8) already have inbox xHCI and USB 3.0 drivers. Whatâs the point of installing another generic driver on top of it if it works already?
I could see the vendor drivers (such as those provided directly by Intel) as those likely have higher performance, but there likely isnât a lot of difference between 1809, 1607, and 1507âs inbox driversâŚ
Ignore this, I see you just did it for testing purposes.
Yes, I hate it to offer any mod+signed driver, which hasnât been successfully tested by myself.
By the way - the biggest surprise for me was, that it was no problem for me to replace the original Win10 in-box USB 3.0 drivers by drivers (= *.SYS files) with the identical code, but with different names, different INF files and a third party digital signature.
It was not even necessary to disable the driver signature enforcement or to force the installation by using the âHave Diskâ button.
Windows might have already matched the .sys files to the âinboxâ approved list via something like hashes, and it doesnât matter if you use another certificate or not. It just knows theyâre valid regardless of how they are signed.
Posting this per request: The most recent 1809 xHCI generic drivers also do not work under Windows 7 (didnât even get to the hub or switch phase,) the xHCI driver itself again fails with âThe driver may be corrupted or missing. (Code 39).â This same error occurs with the 1607, 1507, or 8.1 drivers.
Windows 8âs drivers get further (see my post a few pages back,) but still fail with an error code. I get the feeling it still might be possible to get 8âs drivers working on 7, but I am not familiar enough with .sys binary level driver modding to even start this process.
You somehow breaked signing protection system, so anyone now can create selfsigned "ring0 viruses" for 64 Oses )
p.s. but it still need rights to import cert to root/trusted storage
p.s. Omicron is probably right, signature stored in catroot storage. if you hve free time, change some byte in any string inside *.sys, resign and check
x64 generic win8 and win10 drivers compiled again new kernels, so win7âs kernel lack exports some procedures
on x32 generic win8 driver has same imports from kernel like on win7, but generate kernelfault on loading time
Which specific bytes should I try to change in which manner?
any byte inside any string, Error=>ErrOr, you will not touch asm code this manner
if you use signtool.exe, it will recalculate cheksum in PE header too