I saw that the most recent 11.6 version of the Intel Rapid Storage Technology driver now lists Windows 8 compatibility, the prior 11.4 version worked on Windows 8 but did not list Windows 8 compatibility. I went ahead and installed 11.6, but it does not appear to start - the icon in the system tray says Intel RST service is not running, and when I click on it to launch the app, nothing happens. I checked the error log and this is what I see:
DOWNLOAD >>>>> https://www.google.com/url?hl=en&q=https://urloso.com/2yLyMf&source=gmail&ust=1719695206795000&usg=AOvVaw01X5vyRzjud8udcsUWu5Aa
Next, I try to manually start the service using the Task manager, but the service starts for only a millisecond before stopping again. Checking the Event Log, and I just see simply "The Intel(R) Rapid Storage Technology service terminated unexpectedly. It has done this 2 time(s)."
I'm seeing the same issue, IRST service not starting due to error. If I disable Asmedia 106x sata controller from device manager all of a sudden the service will run, then if I enable the device again it will crash iastoreui.exe.
My OS is Windows 7 x64, with 3 SATA disks and a SATA DVD unit. All this stuff is connected to the ICH9R and the controller is in RAID mode. No issues before today. I have recently updated the IRST to 11.6 without problems.
Under the device manager, i saw that the Marvel controller did not appear in the device list. I switched the the device manager to the view for connection tree, and i noticed the new disk drive was connected to an intel IDE chip (!). So i figured that IRST attempted to take control over a non-chipset controller, causing the crash.
I had to provide the correct drivers to the marvell, so i have downloaded and installed the Marvell driver 1.2.0.68 provided for the Asus P6TH Deluxe (the only one i have found, although i have a Microstar) and... YES, it works, i see the Generic Marvell 61xx in the Controllers list and now iastorsvc starts without crashes.
mom4751, Thanks for your work on this. My issue was similar but the controller was a JMicron JMB362 that the Intel drivers had taken control of. Once I installed the correct JMicron driver the Intel RST drivers and services loaded correctly.
So if you do not add a specific driver for each 3rd party controller, they are seen as Intel devices, the IRST thinks they are Intel parts and tries to take control on these ones too. But they are not really Intel parts, so crashes.
No i did that las night, enable and disable all the SATA related (marvell and jmicron) that didn't work. Lucid is software which im not using it. Asmedia is usb3 related which i wont disable. The other 6 SATA are Intel.
This topic of the Intel RST service not running has been discussed here for a while, and I would like to contribute my experience. Actually, thanks to this forum, I was able to solve my problem.
Since I did not use the "additional driver" feature during Windows installation, I had to update the driver from the Device Manager. In this case it is important to know that as long as the controllers use the standard driver (which conflicts then with RST), they show up under "IDE ATA/ATAPI controllers" in the Device Manager. It might not be always obvious, which of the controllers is which device in the Device Manager, and I needed some trial and error, since there was a multiple choice. Fortunately, the special drivers only install on the correct device.
After installation of the special drivers, the controllers are not listed under "IDE ATA/ATAPI controllers" anymore, but under "Storage controllers" (as also the Intel SATA RAID controller). There, they show up with the correct name and the manufacturer.
With this thread i managed to pinpoint my "problem", like uob's was the extra Via VT6330 controller of my m/b (1394 & 2port IDE), the problem is that i cant find any driver for that controller for windows 7, and i confirmed that by disabling it through bios, RST gui works ok...
The Rapid Storage Technology service (RST) seems to want to enumerate all SCSI controllers\disks and some cause the service to crash. In my case it was the Microsoft iSCIS driver. Disabling the driver fixed "Faulting application name: IAStorUI.exe" and "The Intel(R) Rapid Storage Technology service terminated unexpectedly".
Constant crashes, the RST console not working ,the Service starting and then failing with BEX errors (buffer oferflows) and corrupted RAID disks which occur randomly, cans cause RAID volumes to be dismounted abruptly while Windows is running (the RAID controler device is still working though, but volumes are in error and on next Boot waindows wants to reformat them as if they were empty).
Each time I need to press CTRL+I at boot to recover the volume, and it does not work reliably (even if the GUI console is not working). Recover sometimes works, but most of the time it cannot complete its work before a new driver crash and corruption occurs on one disk. These drivers are extremely unstable !
BEX errors (BUFFER OVERFLOW) are simply unacceptable at the driver level (which is supposed to run in fail safe mode, and that CANNOT be uninstalled when running in RAID mode). Unfortunately, the Microsoft driver does not work, and the old Intel driver 8.6.9 is dramatically slow.
Intel suffers now from low quality code with insufficient testing in its IRST drivers (supposed to be used on mission-critical servers) : their programmers should be fired, or Intel should ask to Microsoft to write and test a decent version of IRST.
Also IRST will crash with any other SCSI or AHCI controler installed. IRST should NOT attach to disks not connected directly to an Intel controler, or not working with the default generic Microsoft drivers for IDE/SATA/RAID : this includes iSCSI (even fom Microsoft), some BlueRay disks, some CD/DVD emulators (mounting ISO images, including the tools from Microsoft for Windows, or virtual image mounters for accelerated hypervisors).
Visibly the IRST driver attempts to enumerate all SCSI devices using a very small buffer (of 144 bytes) when the data blocks returned by drivers will frequently be more than 1500 bytes). However it seems that some SCSI drivers are correctly returning the "buffer size too small" error when calling the Win32 API, but they then return sometimes this error by indicating a buffer size which is still too small (by some bytes) to safely perform the query. When the IRST driver perform such calls, it should allocate a bit more than what is indicated by the error value returned (notably because there are also alignment contraints): ideally the driver should round up the sizes to the next memory page size, i.e. if the driver returns that the 144-byte buffer is too small and the buffer should be AT LEAST 1434 bytes, and the system memory page size is 4KB, then the driver should allocate a full 4KB page as the query buffer, not trying to allocate ONLY the suggested minimum !
Various calls to the Win32 API are not checked. When this affects the IRST management services (just used to control the recovery process in a RAID configuration) or the IRST GUI icon launcher, this is not so critical, but in the kernel-mode driver code (iaStor*.sys), this bug is extremely critical !
I notice that there are much more competent contributors to this forum. Nevertheless, I would like to report a recent finding, which perhaps might help in one or the other case. For details, please see also my original report of January 14, 2013.
However, when I attached two external harddisks (in one casing and over one eSATA cable), only one of the disks was recognized, and the Intel RST crashed again (it was running fine, before I used the JCMicron controller for the first time).
I noticed that the JCMicron controller did not have its specific driver installed, but the generic driver from Microsoft. Hence, I checked on the Gigabyte website for the proper driver. However, Gigabyte does not provide the driver for the JCMicron controller, only for the Marvell controller and the Gigabyte controller on the same mobo. This is obviously bad and not correct.
So, I had to check on the website of JCMicron directly and found a suitable driver. JCMicron mentions that the license for these drivers is "only in order to test the controllers". However, I downloaded and installed the driver for both channels of the JCMicron controller. And - first, Intel RST is running properly again. Also, both harddisks in the casing are correctly recognized. Hence, this driver is necessary, in order to properly operate the controller. I am disappointed that Gigabyte does not provide the drivers on their website.
Perhaps, it may be necessary to check for all non-Intel controllers on the mobo, even if the mobo manufacturer does not provide specific drivers, you might want to check on the website of the controller manufacturer directly. Perhaps there is a specific driver that could help you to solve the problem(s).
SUMMARY for my situation: the Marvell is composed of a SATA bus and eSATA bus. When the Marvell is set to AHCI or RAID in the bios, RST will not start. My testing shows (that for me) it is the Marvell eSata bus (with or without an actual eSata HDU attached) that prevents RST from starting, while the Marvell sata bus seems to co-exist OK with RST (however, this may not be true if HDUs instead of optical devices were attached on the sata bus: untested by me). Again, see screen shot for the full picture and for my workaround.
**UPDATE: (12-15-2013) I finally tracked down a newer version of the Marvell driver (1.2.0.1019, from the Intel website), which moved the Marvell SATA bus device from under the "IDE ATA/ATAPI" tree in device manager TO the "Storage Device" tree. Like previous poster UOB mentions, that seems to be the ticket. Once the Marvell SATA was positioned there, the RST startup conflicts went away.
Intel does not verify all solutions, including but not limited to any file transfers that may appear in this community. Accordingly, Intel disclaims all express and implied warranties, including without limitation, the implied warranties of merchantability, fitness for a particular purpose, and non-infringement, as well as any warranty arising from course of performance, course of dealing, or usage in trade.
7fc3f7cf58