Greetings to the entire Win-Raid Forum community ! Below my first post:
The “Tested AHCI drivers” section at the beginning of this post reads:
“Win10 v1809 in-box MS Standard AHCI driver named storahci.sys (dated 09/15/2018, shown as being dated 06/21/2016)”
Perhaps the correct date is 06/21/2006, that is what is shown in my computer Device Manager under “IDE ATA/ATAPI > Standard AHCI SATA Controller.”
If not, my storahci.sys version is 10 years old …
I doubt it that Fernando as made such mistake… Windows version?
EDIT: Then it may possible due the OS channel. I think Fernando adresses only consumer channel OS.
I have Windows 10 Enterprise LTSC Version 1809 Build 17763.3232 fully patched.
Anyway, the real reason for my intervention was something else:
Although, as stated above, the date of the storahci.sys driver shown in my computer Device Manager under “IDE ATA/ATAPI > Standard AHCI SATA Controller” is 21/06/2006 , the creation/last modification date of the file found in “C:\Windows\System32\drivers” is 09/02/2022 (keep in mind that the OS was installed in January 2021).
Also, the digital signature of the storahci.sys file appears to be affixed on 19/01/2022.
How can be explained the differences between the dates shown in Device Manager and those in the storahci.sys file found in “C:\Windows\System32\drivers” ?
Well…i dont, ask MS. As a long as i achieve a stable, up to date system ill ignore this.
I suspect you have your own suspicious on some thing related to the OS image, origin of source…other issue, due to your carefully approach on a MS driver date/ digital signature… you dont even tell us what the HW you have or the SATA HW device id or why not using specific Intel/AMD driver…
Anyway sorry but its not an issue to loose time on it, maybe our forum founder Fernando can give you a little more inside of this, good luck.
@glstor
Since several years all Microsoft drivers, which are in-the-box of modern MS Operating Systems, are wrongly dated 06/21/2006, although they are much newer (they were usually compiled at the same day/month as the OS itself. The reason may be to simplyfy the replacement of the generic MS driver by any later than 2006 released specific driver, which has been delivered by the manufacturer of the related device.
Note: The OS own Device Manager doesn’t check the exact date of a driver (= *.sys file), but just looks into the related text (= *.inf) file and shows the date, which has been edited there.
@MeatWar
The origin of my Os installation is trusted, but reading Fernando’s initial post and doing some checking on the type of driver I was using, I was wondering why my storahci.sys was from 2006 while Fernando indicated 2016 as the date of the same driver.
For completeness, the source of the installation of my Os .iso file, is the Microsoft site for large corporate customers who have signed a Volume Licensing contract, so no doubt exists about the integrity of the Os image.
The hardware is an Acer Aspire V3-771 laptop with two 2.5-inch Sata drive bays, one port is Sata-300, the other one is a Sata-600 with a Samsung SSD 860 EVO 500GB.
I am not using a specific driver for my Intel chipset because from research done when I’ve installed the OS (January 2021), Intel seems to have abandoned driver development for my chipset. The Microsoft driver works fine and, from the tests at the beginning of this post, it appears that the difference with the Intel drivers is negligible.
My chipset is recognized by Aida64 as Intel 7 Series/C216 Chipset Family (North Bridge: Intel Ivy Bridge-MB IMC , South Bridge: Intel Panther Point HM77).
@Fernando
Fernando you are absolutely right: the date 21/06/2006 is intentionally wrong to prevent Microsoft drivers from taking priority over manufacturer’s drivers, see link below
… it would be interesting to understand why Microsoft has been able to impose a digital signature requirement on manufacturers device drivers, and is unable to adopt a policy that prioritizes manufacturers drivers over Microsoft drivers without having to adopt the trick of the date set to 21/06/2006.
Perhaps an appropriate additional field in the driver .inf files the would have sufficed to avoid the date trick …