Zitat von Fernando im Beitrag #645So the driver itself may have been compiled on 5th December 2014, but the final steps were done by Intel on 27th of January 2015.

The way I see it, Microsoft is a "3rd party" in this case, the actual driver is Intel's so the important date is the compilation one (that's the date that the .inf files include and is shown at Device Manager). There are also non-WHQL drivers, Intel is important not Microsoft. The final step done at 27/01/2015 is basically copying & packaging the files before release.

Similar to ME firmware, the actual .bin inside the official .zip package from their site may show a date of 05/01/2015 but the actual firmware a date of 31/12/2014. The correct date is the latter, compilation not PV release.

Zitat von plutomaniac im Beitrag #646The way I see it, Microsoft is a "3rd party" in this case, the actual driver is Intel's so the important date is the compilation one (that's the date that the .inf files include and is shown at Device Manager).

This is what I expect as well, but unfortunately the users cannot always trust the INF files entries, which are shown by the Device Manager.Example:Here are the first lines of the 64bit ISCTD.inf file, which you can find within the attached original Intel Smart Connect Technology (ISCT) driverpack v5.0.10.2936 WHQL:Please compare the red marked INF file entries with the reality:Note: A wrong driver version and compilation date shown by the Device Manager may not even been recognized by many users, but I was wondering why I was not able to get the 64bit ISCT Driver v1.1.0.0 WHQL installed while running Win 8.1 x64 until I realized the wrong [Intel.NTx86] entry within the 64bit INF file.

What you have written may have been valid in the past, where the hardware manufacturers have sent the finally compiled drivers to Microsoft, got them back a few days later with a WHQL signature within the .CAT file and released them without touching the SYS and INF files again. Nowadays it seems even possible for the hardware manufacturer to silently update an already finally compiled driverpack.

Zitat von Fernando im Beitrag #647This is what I expect as well, but unfortunately the users cannot always trust the INF files entries, which are shown by the Device Manager.

That is indeed some sloppy work by Intel, total screw up (wrong version and wrong architecture). It's not the norm though, this looks like a one-time thing. For everything else (that works as it should), the digital signature will give you an accurate estimation of the file's date.

Zitat von Fernando im Beitrag #647What you have written may have been valid in the past, where the hardware manufacturers have sent the finally compiled drivers to Microsoft, got them back a few days later with a WHQL signature within the .CAT file and released them without touching the SYS and INF files again. Nowadays it seems even possible for the hardware manufacturer to silently update an already finally compiled driverpack.

This should not be possible to my knowledge, it would defeat the whole purpose of digitally signing a driver. When MS signs a package, every file inside (.inf, .sys) is hashed and RSA-encrypted via Public-Private Key inside the catalog file. It's called thumbprint. If Intel tries to modify the .sys or .inf files after receiving the signed catalog file from MS the latter will automatically become invalid. Details.

Zitat von plutomaniac im Beitrag #648This should not be possible to my knowledge, it would defeat the whole purpose of digitally signing a driver.

Do you really believe, that any MS employee is checking the content and functionality of the SYS and INF files before giving the WHQL stamp?I have seen complete series of different NVIDIA Ethernet drivers (all of them WHQL certified) with exactly the same wrong INF file entry. When chipset manufacturers like Intel or formerly NVIDIA are going to create the matching INF files for a freshly coded new driver version of a certain development branch, they just copy and paste the INF file content of the previously released drivers and change only the driver version and date. I doubt, that they will update the related INF file entries, if they should realize and correct later on a wrong code within the SYS file.

Zitat von Fernando im Beitrag #649I have seen complete series of different NVIDIA Ethernet drivers (all of them WHQL certified) with exactly the same wrong INF file entry.

MS doesn't care about that, the signing is done automatically. If an OEM gives them a "broken" inf file it will still get hashed and then added to the catalog file encrypted. It's a separate procedure. An OEM can indeed just copy-paste the previous .inf file, change the version and then send it to MS for WHQL signing. The resulting catalog file from MS will include the hash of the inf file provided by the OEM. After MS signs the contents of the package (.sys, the broken .inf etc) the OEM cannot alter them (to fix the broken .inf for example) without breaking the previous certification. They would need to re-sent it to MS to get signed again. I never said that we should check the .inf file but rather the digital signature of the .sys file. If the OEM spotted an error at the sys file after it was signed by MS, they would fix it first (new digital signature) and then re-send it to MS.

@ plutomaniac:You may have misunderstood me. I have never argued, that Intel may have modified the content of their driver files after having gotten the WHQL stamp from Microsoft. What I wanted to point out is, that a) the Device Manager just shows the version and date of the driver, which is layed down within the related INF file - regardless if these entries are correct or not - andb) these INF file entries may be wrong.Undoubtedly Intel has done something with the files of the RST(e) drivers v13.6.2.1001 on 27th of January 2015. Otherwise they wouldn't have gotten a new date. A simple packing procedure doesn't alter the dates of the affected files.Now we should stop this off-topic discussion.

Zitat von snadge im Beitrag #652which is the most important one to pay attention too?

It depends on the size of the files, which are mainly or very often read resp. written with your computer.For the daily work of a "normal" user the most important benchmark results are the 4K ones, but for video encoding tasks the "Seq" and "4K-64Thrd" scores may be important as well.

Do you know what sort of Intel drivers are best for the new X99 chipset?Would like to enable RAID 0.

AFAIK, I was using the latest version: >Intel RST(e) AHCI/RAID Drivers & Software Set v13.6.2.1001 WHQL, However I just saw the new (to me) drivers: >64bit Intel RSTe AHCI/RAID Drivers v3.8.1.1006 WHQL for Win8/8.1 x64I have downloaded the v3.8.1.1006 and I could not find the setup.exe application to install the Intel RSTe Software, I could only see the drivers need to load up while you are installing windows.

Zitat von Safado2 im Beitrag #654Do you know what sort of Intel drivers are best for the new X99 chipset?Would like to enable RAID 0.

If your mainboard BIOS offers the option to switch from RSTe to RST, I would install one of the RST(e) RAID drivers of the v13 series.

ZitatAFAIK, I was using the latest version: >Intel RST(e) AHCI/RAID Drivers & Software Set v13.6.2.1001 WHQL, However I just saw the new (to me) drivers: >64bit Intel RSTe AHCI/RAID Drivers v3.8.1.1006 WHQL for Win8/8.1 x64I have downloaded the v3.8.1.1006 and I could not find the setup.exe application to install the Intel RSTe Software, I could only see the drivers need to load up while you are installing windows.

Please read the complete RSTe drivers section of the start post. Then you will find, what you are searching for.

I have no idea of my board offers the option to switch from RSTe to RST,however I've seen at the Asus website that I can download the Intel Rapid Storage Technology Driver software V13.1.0.1058,that leads me to believe that you might be right.

Zitat von Safado2 im Beitrag #656I have no idea of my board offers the option to switch from RSTe to RST,however I've seen at the Asus website that I can download the Intel Rapid Storage Technology Driver software V13.1.0.1058,that leads me to believe that you might be right.

The Intel RST drivers v13.1.0.1058 do indeed support the original X99 chipset Intel SATA Controller, but only in AHCI and not in RAID mode.

Zitat von Safado2 im Beitrag #658Then the Intel RST(e) AHCI/RAID Drivers v13.6.2.1001 will just suffice to run RAID 0 on a X99 system chipset?

There are at least 2 options to get any Intel RST(e) RAID driver v13.x.x.xxxx installeed onto an X99 RAID system:a) You set the Intel SATA RAID Controller to "RST" within the BIOS (this option requires to BIOS ability to switch the DeviceID from DEV_2826 to DEV_2822).b) The other option is to install an Intel RST(e) RAID driver v13.x.x.xxxx, which has been modified by me. You can find them >here<. In this case you will use the original DeviceID (DEV_2826) of your on-board Intel SATA RAID Controller.

I have downloaded your modded RAID Drivers, however can you explain what do you mean with this:

" have to be installed manually from within the Device Manager, only usable with Win7 x64 and - after having disabled the driver signature verification - Win8 x64)"

AFAIK, I thought I could load up your modded drivers while doing the windows 8.1 Pro installation and once the windows it's all installed, I would just need to install the Intel RST_64 console and voila! Al done, but it seems that because these are modded drivers, I need tro install them in a different way.

Can you please share the right sequence to install your modded drivers?