So this has plagued me for quite some time. I’m inclined to say years. I do remember such a point that it wasnt an issue, but iirc it was IRST ~15.xx and prior.
I’m unsure what changed but post that point, all IRST drivers have caused my system to temporarily freeze any time a hard drive wakes from sleep.
I know, the easy out is to disable sleep. Unfortunately I run 11 hard disks and many arent accessed often, so between heat, energy, longevity… preference, you get the idea.
If a drive spins up, the entire pc is unuseable until its done. If im gaming - freeze. if im working, cant even move the mouse or carry on while i wait for it to finish spinning up.
this does not happen with the standard ahci driver from microsoft. Also doesnt happen with the irst(e) drivers which i not only find odd, but arent for my board anyhow.
Does anyone know what changed in relatively recent history that caused this to happen, or if theres a means to eliminate the hang without resorting to disabling drive sleep or reverting to the generic driver?
Loooooooooooooong time lurker and this finally forced a registration so i can let the pro’s at it 
@klepp0906 :
Welcome to the Win-RAID Forum!
If you really want help, you should give us additional information about
a) your current system (OS/mainboard/chipset/SATA mode),
b) the Intel RST/RST(e) driver versions, which caused the freezing, and
c) the reason why you don’t want to use the OS in-box SATA driver.
Regards
Dieter (alias Fernando)
Hello, i’ll provide what information I can.
OS - Windows 10 Pro
Motherboard - Asus maximus x formula (z370 chipset)
Driver versions that caused freezing are literally anything for almost the past year. all 17.x for certain. Have been “re-trying” them semi regularly to see if the issue has been resolved.
I prefer to not use the generic driver for entirely arbitrary reasons tbh. I know the performance difference (if any) is likely within margin of error. I’d just prefer to have hardware which has an associated driver paired with such.
hence my reason for using the irste even though its only supposed to be for XSeries boards and places my sata chipset under Storage Controllers instead of IDE/ATAPI controllers in device manager (like irst & generic do).
it at least avoids the entire system halt whenever a spun down drive is accessed.
The issue is sprinkled all over google but everyone’s go-to solution is always to set drives to never sleep. With 11 hard disks, thats just not reasonable.
Trying to find a middle ground or if theres anything else i can do. You guys are the professionals in that(this) arena so i figured if i cant find a way around it here, it is what it is.
@klepp0906 :
Thanks for your quick response.
Due to the fact, that you
a) obviously have connected a lot of mechanical working HDDs to your mainboard and
b) got the same problems with a lot of different Intel AHCI drivers, which natively do support your Intel Z370 chipset,
I seriously doubt, that your issue is driver related.
What about the PSU? Each restart of so many HDDs or their wake-up from sleep is a big stress for the PSU.
Other questions:
1. How do you install/replace the in-use AHCI driver (manually from within the Device Manager or automaticly by running the installer of an Intel RST/RST(e) Drivers & Software Set)? If the latter, did you always previously uninstall the previously working Intel RST Software?
2. Which Intel RSTe drivers did you test and what was the reason for trying to get drivers installed, which were not designed at all for your Intel chipset?
I’d be inclined to agree except for
a) the problem wasnt present with ANY much older irst driver, any irste driver, or the generic microsoft driver
b) the exact issue is referenced elsewhere on the net
c) I use a 1500w evga psu (oddly enough, the issue doesnt present when im opening something like the recyling bin, or macirum which spins up all of them at once, only if i try to access a single sleeping drive via windows explorer)
1) i replace the drivers 9/10 times via right clicking the inf > install. or at times via device manager > update driver > specify location > navigate to driver folder.
2) as far as the irst(e) drivers go, ive been using those since the 5 series up until current. In all honesty i didnt realize they were limited to the x series boards until after i had already begun using them. It was surprising since they A) install fine and B) circumvented that doozy of an issue for me lol.
I’m using the 6.2.2.1006 as we speak having just upgraded from the prior release a few weeks back.
as i mentioned, i revisit this every once in awhile in an attempt to see if its worked itself out as id definitely prefer to be using drivers that are indicated as being for my board and identify as such in device manager.
I appreciate youre being thorough 
@klepp0906 :
How old are your 11 HDDs and how heavy have they been used in the past?
If so, why didn’t you stick to the "old" ones? Newer drivers are not automaticly better.
If so, why didn’t you stick to the "old" ones? Newer drivers are not automaticly better.
lol again, common sense prevails. I have a proclivity like many in this arena (i assume) for knowing that from a practical standpoint, but being compelled to update regardless. Every month or so i run DUMO to see whats out of date, and automatically update all my drivers. Intel releases them often enough that i’d have to imagine theyre improving in general over time though no? To what end i have no idea, it goes well above my paygrade - but otherwise they wouldnt release them nearly as frequently one would think.
Theres also the fact that microsoft will no longer allow installs with the 15x series or so i just remember reading about. Or stop letting upgrades through rather. So whatever was implemented during that point in time was drastic enough to cause microsoft to disallow older iRST, but also likely when this began to be a thing.
I’m starting to come to the realization that my choices are going to be the same here lol. Either keep em spinnin, or use a driver where it doesnt happen. aka not irst.
Theres also the fact that changing to the generic from intels drivers (irst or irste) uses a different drive # for the drives for whatever reason and it screws up macrium at first lol.
Hrm.
@klepp0906 :
My advice: Stop running the DUMo tool and try the mod+signed Intel RST(e) driver v13.2.8.1002 dated 07/09/2015, which is according to my experience one of the best Intel AHCI drivers even for systems with a modern Intel chipset. Don’t forget to import the Win-RAID CA Certificate before you are going to install it.
very sound advice, and thank you for the suggested driver. Sounds like my next stop. Will let ya know how it goes.
thanks again, appreciate it!
@klepp0906 :
Don’t forget to look into the “Add/remove Programs” section of the Control Panel for any listed Intel Rapid Storage Technology entry. If you should find any, delete it and reboot before you install any Intel AHCI driver.
Hi, a year ago I posted here
New intel build, odd behaviour
for the very same problem.
At a certain point an EFI driver update for my board (Asus Prime Z370-A) was released and the problem disappeared.
After many windows updates and a couple of new Intel IRST drivers, the problem reappeared and the only way to solve it for me was to disable sleep on the drive I use for backups.
My other two drives are in a RAID0 array, and keeping sleep active on the spare drive would freeze the system anytime the spare disk had to be accessed or read (even when opening task manager).
I’m very interested in klepp0906 findings.
I cannot remember which combo of EFI driver + IRST driver would get rid of this annoying problem, but I suspect that the many windows updates of the last year could play a part in this, so I’ve pretty much given up on finding a solution.
Fortunately disabling sleep on my only backup drive is no big deal, but I’m absolutely positive that a couple of years ago, on my previous setup, this problem didn’t exist whatsoever.
@Lurk :
well i installed Fernando’s driver, and the problem did disappear. (as i noted, it was not present in old irst drivers)
unfortunately i also began having a problem with my drives never sleeping so until i solve that i cant dive more into this. Now im presented with a problem where windows has changed my device enumeration around and my OS drive is number 7. The struggle
imagine having to scroll down 7 drives to deal with backing up your system drive in macrium #sigh
anyhow, thats another topic.
Back to the point, this problem more than anything has driven me towards disabling sleep on my drives. However I run 12 drives and the heat + power draw and extra wear just doesnt seem worth it. The alternative seems to be using the wrong driver for my platform, or a 5 year old driver which im fortunate enough has been modified to be usable
Still on a mission to try and find the best solution overall At this point as i mentioned, its either fernando’s drivers or using IRSTE drivers, which while not meant for the z370 chipset, are different enough that they dont cause the issue.
for some reason using generic microsoft drivers doesnt sit well. Same as refusing to use generic NVME drivers. (those actually have pretty large benchmarked performance ramifications).
EDIT by Fernando: Unneeded fully quoted post and blank lines removed (to save space and for better readability)
wonder if it has anything to do with this
https://blogs.visigo.com/chriscoulson/ssd-freezing-fix/
i doubt it, at least not directly due to age of the post. Still it does revolve around the handling of coming out of a lower power state.
those exact keys dont exist, at least not on my build. but several related do nearby. Unfortunately it quickly goes above my pay grade so to speak.
found something interesting. Drivers such as the 13.x.x variant that doesnt present the issue - iaStorA, see here HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\iaStorA\Parameters\Device
now drivers such as the new IRST which DO present the hanging - iaStorAC, see here HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\iaStorAC\Parameters\Device
See all the strings referencing HIPM and DIPM? I’m gonna venture the problem lay there. Not sure what those keys do yet, but i think they override or ignore the OS power management settings or something. Gonna dig more.
edit: just swapped over to irste (which dont have the issue) to test the theory. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\iaStorE\Parameters\Device and look what its missing?
all the
Controller0Phy0DIPM
Controller0Phy0HIPM
strings that are present in the new IRST drivers. I’d venture its some kind of funny business going on with HIPM/DIPM. Windows 10 (at least on desktops) appears to default to HIPM (at least on the balanced power plan). I’m going to try to set it to active and see what happens.
if it works, then your options are probably setting AHCI Link power management to Active, using a driver without those dword values (or altering/deleting them).
will take a bit to see.
and thats a fail. deleted all those dwords to match the others, and still does it. looks like im rollin back again. oh well. about to toss in the towel on that travesty. been dealing with this too long to spend too much more time on it.
one more stab at this which feels promising (but so did the former).
I returned all the new/current HIPM/DIPM qwords to their defaults.
I had tried default, I had tried them all removed, I had tried them with only DIPM off and HIPM on as is windows default. All still had the soft hangs.
I was looking through the inf’s and noticed a difference in the messaging signal interrupt setting. A drastic difference. Current IRST(e) have the MessageNumberLimit as 1. The old non-problematic IRST drivers also have it as one (including fernando’s modded). Current problematic drivers have it set to 80!!
Now for testing im using the MSI mode utility, and MSI Is brand new to me. However its my understanding under most cases the higher the number, the more problematic it can become with one of the problems being hangs such as what many experience.
(oddly enough samsung sets their m.2 driver at 2048 lol)
its my last ditch effort before i give up on current irst completely.
towel tossed in. messing with the the MSI didnt save it. good luck to the next guy
found this during the endeavor which is interesting. naturally went unanswered but it provides at least some more technical info.
https://forums.intel.com/s/question/0D50…?language=en_US
Please dont toss anything else, do urself a favor start from scratch with a clean OS and drive by drive…im almost sure that the driver will be stable and wont freeze…if it does, then u have a hw i/o issue. Dont try get an answer in a pile of junk OS full of tryouts and modifications…hopping that a miracle fix will come out from it, u wont get any clear understanding of the issue. Troubleshooting steps is always the way. A simple i/o cable, voltage drain, disk surface, disk heads, firmware, bios…u name it
unfortunately it is a clean OS. actually in the midst of setting it up atm, hence why im revisiting this "problem"
the fact that it doesnt soft-hang with IRST pre ~15.x, doesnt soft hang with M$ standard ahci, and doesnt soft-hang with any irst(e) up to and including the newest - certainly puts it well beyond the particular OS install imo anyways.
its been present for ages. Ever since the migration from ~15x to higher irst.
its all over the web. Apparently the general consensus is ditch the irst drivers and use standard, but standard puts my drives all out of order. It puts my OS driver as Disk 7. Makes it a bit annoying every time i have to navigate to it in xxx software.
Others just avoid sleeping their disks. For me with 7 inside my PC and 6 outside, not an option either. My data is very important to me so i’d prefer not to run all my drives 24/7
having my OS drive not as the first disk is a deal breaker for me, as is the random hangs when disks spinup, so that leaves me with the 13.xx drivers fernando signed to make usable on current win10, or the irste.
the performance is marginally better with the old irst from win-raid, but probably within margin of error. Oddly enough that part is inconsequential to me. What is not (warning, im very ocd) is the fact that fernando’s display in the proper area of device manager, but are named incorrectly and advertise as being “by fernando” (no offense fernando lol). The irste on the other hand, dont display under IDE ATA/ATAPI Controllers and instead display under Storage Controllers. Also named incorrectly but in a different way. They say theyre for C600/C220+ chipsets or something like that which is evidently what comes on the X99+ boards.
at least i know what it isnt. It isnt related to HIPM/DIPM in the sense that a particular mode is the problem. It isnt related to Message Interrupts or their limit. Its something revolving around APM and waking the drives though. It happens at random when the OS decides to spin one up for whatever reason which is what makes it especially taxing as it soft locks your pc for ~5 seconds at least.
im a glutton for punishment.
i noticed the non-offender drivers point to their relative driver, aka iastorE.sys or iastorA.sys. The irst (newer ones) point to iaStorAC.sys but also an RstMwEventLogMsg.dll and a RstMwService.exe
I wonder if one of those "extras" is the root of the issue.
I tried finding the service in services.msc to disable and test, but not seeing it.