[Problem] v17/18 platform Intel RST drivers may overtake Control of all SATA+NVMe SSDs

The Intel RST driver version downloaded on my desktop with a Z370 chipset through Windows Update and is ready to install

Device Manager nags with a pop up message “Your hardware settings have changed” when clicking on the driver tab of the Intel 300 Series Chipset Family SATA AHCI Controller.

A warning is posted of reports about non-RAIDed NVMe SSD’s being completely overtaken by the RST drivers (v17 v v18).

My desktop has one system drive that has an M.2 PCIe connected SK Hynix NVMe SSD.
Approximately two years ago I changed the SATA controller to AHCI mode in the BIOS. The BIOS used to be configured in RAID mode. It used to have the Intel RST Premium Controller installed.
This might explain the pop up message in Device Manager.

Please provide more specifics on SSD’s being overtaken by the RST drivers.
Searching through posts #2000 through #2475 apparently omits what details were involved with those drivers version 17 platform driver.

EDIT by Fernando: Thread title customized and shortened

@Rathlin ,
I have reported my difficult experience on a Z390 machine after updated by inadvertance to Intel RST v17.9 and even v18.x branch.
Yes my non RAIDed Samsung NVME SSDs were beeing completly overtaken by RST v17.9 and up.
So, Samsung NVMe performant drivers were replaced by Intel less performant driver.
Yes my SATA SSDs RAID0 array was handled by Intel RST v17.9 and up.
Trying to coming back to a situation to get back Samsung NVMe driver installed and running was a ‘nightmare’, but finally succedeed with configuring BIOS settings in pure SATA Mode = AHCI instead of RAID, and using a RST v15.
A surprise is the AHCI Mode does handle as well RAID0 Array.
See all the numerous posts starting #2842 on the sub-forum Intel RST/RSTe driver…

@Rathlin :
Welcome to the Win-RAID Forum and thanks for having started this thread.
Due to reports of our Forum members 100PIER and Frames I have yesterday updated the start post of >this< thread. Within the chapter “Important remarks regarding the usage of the 32/64bit RST(e) Drivers or the complete RST(e) Drivers and Software Set” I have added the new point 4 with a “Warning” regarding the installation of any Intel RST driver, which belongs to the RST v17 or v18 platform.
If you want to know more, I recommend to read 100PIER’s recent report about his experiences with his Intel Z390 chipset system, which starts >here< and ends >here<.
Enjoy the Forum and report here about how you solved your topic related problem!
Dieter (alias Fernando)

@100PIER :
Thanks for having already posted your statement as an affected user into this thread.
Your last sentence contains a typo: The post #2842 hasn’t yet been written. The correct post number is 2428.

I’m not sure if the issue is only related to RST drivers changing EFI variables (settings, maybe a hidden one), but I’ve disabled this “feature” in my ported drivers.

In case someone can try or wants to try them to see if they prevent the undesiread behavior, check out this thread at MDL:


Thank you for welcoming me to the Win-RAID forum.

If I may point to one major difference between 100PIER’s system configuration and my system, it is that 100PIER has a RAID array and I never had a Raid array. As I mentioned, I have one NVMe SSD system drive. I also have one HDD spinning drive. They’re on a Dell desktop that has a Southbridge Z370 and those who’re familiar with Dell desktops know that a lot of their machines are factory pre-configured with the BIOS set to ‘RAID On’ rather than AHCI, regardless of whether or not the system is even running a RAID array or not.


There hasn’t been an driver update installed for the Intel 300 Series Chipset SATA AHCI Controller under IDE ATA/ATAPI controllers ever since I changed from RAID On to AHCI mode in the BIOS.
I can see under C:\Windows\System32\DriverStore>FileRepository that the system still has the Intel iaStorAC.inf Storage controller and with that driverpack an additional 11 files where one of those files is the iastorAC.sys driver.
It appears I have no way to know what driverpacks downloaded from the WU server that are in queue and ready to install. One would reason that only the iaAHCIC.inf driverpack should have downloaded. And as you mentioned in post #2462, there isn’t a way to install one particular driver named iaAHCIC.inf by pointing to that INF file even if I could.

It’s concerning to think that just by installing the RST(e) drivers v17 from Windows Update, I could potentially have an issue. I gather this warning also included non-RAIDed SSD’s because from the test system with only the single Kingston SSD ??

Your post #2429 provides steps to return the user’s system to the previously used storage. Those steps however are for a non-Microsoft Controller under “Storage Controllers” in Device Manager. I happen to have the generic Microsoft NVMe controller installed.

Perhaps you could comment on a benefit of attempting to install the RST driver v17 platform through Device Manager instead of restarting the system. It would be a help knowing too whether there are steps like in post #2429 to return back to the previous used AHCI controller should anything happen . . . (other than a restore point which I have already created)

Re: System configuration : I don’t have my system config profile setup yet because, and I may be wrong about this, but I don’t believe I’m permitted to do so until I post more on the forum.
The following information may provide more clarity.
1) Intel RST Premium Controller originally installed when Windows 10 first installed on the new system.
2) After changing the SATA controller mode in the BIOS from RAID On to AHCI, the Intel RST Premium Controller drivers remained installed. I did not manually attempt to uninstall the RST Premium Controller software.
3) The change to the SATA controller mode in the BIOS triggered the Microsoft (generic) Standard NVM Express Controller to install i.e, replace the Intel RST Premium Controller.
4) I have an Sk Hynix NVMe SSD. That manufacturer does not provide their own firmware/NVMe drivers like Samsung provides (or at least they don’t for my NVMe SSD anyway).

@Rathlin :
It is not easy to understand your problem (which performance/stability issue has your PC currently?) and which drivers (for the NVMe and for the SATA Controller) you want to use.
For a better understanding please post a screenshot of your system’s Device Manager after having expanded the sections “IDE ATA/ATAPI Controllers” and “Storage Controllers”.

One thing that can often lead to misunderstandings on any forum is trying to describe an issue using only text.

Actually there is no performance or stability problem - Yet
That is because the RST(e) v.17 platform is still pending a system restart.

The other thing is, when replying to your post, I’m now no longer seeing the buttons within the editor to allow me to upload a screen shot.
I saw the editor buttons after my first reply to your post. Now, they’re all gone. All that exists is “One” button and that button only allows me to quote text.

I’m really not sure how to upload the screen shot from device manager without the editor tool . . . unless I would start a whole new thread. And without it, I can’t help clarify your questions.
Hey, Sorry, Fernando. I’m still new to this forum and how the editor works. The edit button needed to be clicked first to bring up the function keys
Here’s some screen shots. Please let me know if this will suffice or if there’s anything else I can upload

Win Raid.png

Win Raid (1).JPG

@Rathlin :
Thanks for the screenshots (I don’t see the difference between them).
According to what I see your system is not affected by the “Control overtake” issue, because the NVMe SSD is using a Samsung driver and your SATA connected device(s) an Intel AHCI driver.
Where is the problem?

My apologies for implying that there was a problem.
The concern of a potential complete overtake was more or less a misinterpreted reading in #4 since it doesn’t mention specifically NVMe SSD from Samsung, or their drivers, or other manufacturer’s drivers. The basis for the misunderstanding could’ve possibly been avoided if ONLY Samsung drivers were mentioned affected in the warning. There were quite a lot of posts that had to be carefully read through too