Hi Fernando, thanks for all your great work. I’m having a problem with your modded RST drivers & would appreciate your advice please.
System is Asrock Z97 Extreme 6 / UEFI RAID mode / 1 x NVMe Samsung 950Pro (boot disk) / 2 x Sata Samsung 840Pro (raid 0) / Win10 Enterprise x64 1803 (17134)
During RS4 testing, benchmark & real world useage showed EFI module 13.2.2.2224 + RST driver 13.44.0.1026 + RST Utility 13.2.8.1002 (writeback cache mode enabled) gave best performance. Last o/s update was INPLACE install of 1803 + your modded 13.44 drivers from this post Link. All works perfectly and Device Manager shows
and System32\drivers shows
With the ‘RTM’ of 1803 I decided it was time for a CLEAN install so deleted existing Win10 partitions, installed 1803, installed Win-RAID certs, rebooted, installed modded 13.44.0.1026 drivers & rebooted. Unfortunately this reboot fails - the only solution is to ‘disable driver signing enforcement’ in the advanced startup options. Checking Device Manager Driver tab suggests that the modded driver has been installed but the details tab still refers to the 1803 inbox driver 15.44.0.1010
System32\drivers folder indicates that the modded 13.44 driver has NOT been loaded
iaStorAV.sys is missing.
Do you have any idea why this is happening? Do I have the most recent 13.44 modded drivers? Have I missed something? (If all else fails I will revert to the official 13.2.8.1002 driver with a slight loss of performance)
Not really. After having successfully installed any driver, it should be stored within the System32\drivers folder and within the System32\DriverStore\FileRepository folder (look for a subfolder name beginning with “iastorAC.inf”. I have no idea why a) the Device Manager of your current system shows for your on-board Intel SATA RAID Controller a wrong (not in-use) Intel RAID driver version and b) the OS has totally erased the previously successfully installed driver from the Sytem32\drivers folder. Maybe I will be able to answer your question very soon, because I am planning to do a clean install of Win10 x64 v1803 onto a RAID0 array of my old Intel Z68 chipset system and to compare the performance of different Intel RAID driver versions.
The most recent variant of the “Universal Win10 x64 Intel RST AHCI & RAID driver v13.44.0.1026 comp+mod+signed by Fernando” is attached, but there is no diffference to the variant you have used, which would explain your issue.
Maybe it is possible to avoid your issue by replacing the Win10 v1803 in-box Intel RAID driver v15.44.0.1010 by an other Intel RAID driver (e.g. v13.2.8.1002 WHQL) according to >this< guide before starting the fresh OS installation.
Thanks for the driver package - although the size of the .rar is the same as the one I have, the contents are different. The .cat & .inf files have different sizes - it looks like your file has more device IDs added. Using this new driver pack, your modded 13.44 installs correctly and shows as ‘Win-RAID CA’ on both the driver tab & driver details page in device manager. Unfortunately, upon reboot Windows still thinks there is a problem unless run with ‘driver signing enforcement’ disabled.
I have compared installation of official 13.2 & modded 13.44 drivers to a CLEAN install of Win10 1803 but see no real difference. In both cases I see: (a) Creation of new iastorv.PNF (precompiled inf) in C:\Windows\INF (b) Copy of iaStorxx.sys driver from driver pack to C:\Windows\System32\drivers (where xx= ‘A’ for 13.2 & ‘AV’ for 13.44) (c) Creation of new iastorac.inf_amd64_xxxxxxxxxxxxxxxx folder to C:\Windows\System32\DriverStore\FileRepository (d) Copy of .cat, .inf, .sys from driver pack to the new FileRepository folder (e) Creation of new iastorac.PNF in the new FileRepository folder
I can only assume the problem is with the .PNF file or that (on a clean install) Windows is making some extra checks re file validity? I am going to switch to official 13.2 driver to avoid further problems but will be very interested to know if you have any issues when you run your next set of performance tests.
@staveley : There seems to be something wrong with the driver integrity check of Win10 v1803 while booting. Here is an example of my own experience: My Z170 system is currently running in AHCI mode. Yesterday I have done a clean install of Win10 x64 v1803 and have tested the performance of different AHCI drivers (the interesting results can be seen within the start post of >this< thread). The last Intel AHCI driver I tested yesterday was my mod+signed Intel RST(e) driver v13.2.8.1002 (Intel 100-Series chipsets are natively not supported). This specific driver ran flawlessly and gave me the best benchmark results of all tested AHCI drivers. Since I got today access to the brandnew Intel RST driver v16.0.5.1095 WHQL, which natively supports Intel 100-Series chipsets, I wanted to check the performance of this newest Intel AHCI driver today and to add the results to those I had published yesterday. The update from the mod+signed driver v13.2.8.1002 to the WHQL certified driver v16.0.5.1095 went flawlessly, but after the reboot I got your wellknown error message. Similiar to your report the only possibiity to get my OS bootable again was to choose the “Advanced Boot Options” und to hit F7 (option “Disable driver signing enforcement”). This verifies, that Microsoft not even trust its own digital signature.
I also can confirm that your signed drivers which were perfectly well working in 1706, stooped to work in the middle of 1709 and actually caused lots of trouble before I understood that I need to disable signature validation on boot…to be able to boot at all. I replaced it with crappy MS drivers and it worked (in a crappy way). Now I am on 1803 and tried to install the same drivers… I install the certificates as usual, and then I try to install your drivers and the (crappy) system says that they are not digitally signed properly!
Obviously MS did that against you and other self-signers… it does not want to accept old signatures so new certificates are needed tested to run on 1803.
And in the Future how do I know then this issue will not re-emerge? This is bad bad bad option to have nice drivers which you know may fail you one day MS will again decide to demand new signatures… and prevent you from even booting your machine… we need a better solution, like utility that checks current status of the certificates and updates them from some server if nesessary.
By the way: I had no problem to get my mod+signed Intel AHCI drivers properly working with my Z170 chipset system after a clean install of Win10 v1803. Even when I got an “unbootable system” thereafter, everything was fine after having disabled the “Driver Signature Enforcement” (has to be done only once and never again!). The related mod+signed driver was still shown within the Device Manager as being correctly signed by Win-RAID CA. Questions: 1. Which one of the mod+signed drivers did you install? 2. Did the Device Manager show them as being digitally signed by Win-RAID CA?
