At this point, this is just informational.
I have an ASUS P6X58D-E motherboard. The RST drivers, before the creators update 1709, were at 184.108.40.2063, along with the Intel RST Management app (I installed that version after the Windows 10 update from Windows 7 uninstalled the old Matrix Storage Manager app.; I used that version to get it back).
After applying the Microsoft 1709 Fall creators update along with the January rollup, my system went into the tank over a period of days in which the first boot after power up would fail with DPC Watchdog errors and a Machine Check and hangs with just a mouse pointer - but would recover after pressing my machine's reset button -- and finally hangs with the wheel of dots and was unable to boot successfully at all. Fortunately, I was able to fall back to 1703 when Windows went into its built-in recovery, and my system is stable again.
I have found a useful post here ( ), and I plan to try the suggestion of installing 220.127.116.112, before attempting again, have an image backup of 1703, and an image of my RAID-1 data drive, and I made a Windows 10 recovery boot USB just in case, as well.
But Intel and Microsoft need to get their heads together on this. A look at the Microsoft Windows Feedback show endless complaints about systems hanging and crashing after installing the Fall Creators Update 1709, and I would guess that more than a few are the Intel RST driver level.
(Note: I tried to install 18.104.22.1683, before I had read the aforementioned article, and of course, my system would not boot - the circle of dots "kept on swimming, swimming, swimming...". But I had taken the precaution of taking a system restore point before that, so recovery was easy. Also, that install claimed it had an error, though the IASTOR.SYS driver files were at the correct level when it was done. So at the very least, that install is buggy.)
Anyone else, please chime in if you have advice, or experience on this matter.
Just quick update. Today I installed RST version 22.214.171.1242.
Although the first attempt at the install came back with a "Fatal Error" a check of the driver version in Device Manager showed the correct version. The user interface did not install.
After a reboot, I then ran: SetupRST.exe -Nodrv
and that installed the UI.
I am now going to let the system simmer for about a week before I try Windows Fall Creator 1709 update again.
I may have tracked down the root cause of the "Fatal Error" message during the install of some versions of RST in my install logs (C:\Users\Administrator\Intel\logs\*.log :
MSI (s) (DC:D0) [09:30:41:005]: Product: Intel(R) Rapid Storage Technology -- Error 1923. Service 'Intel(R) Rapid Storage Technology' (IAStorDataMgrSvc) could not be installed. Verify that you have sufficient privileges to install system services.
Unfortunately, I have not yet found anything about how to resolve this. (If one uses -Noservice, then the UI won't install either). Error 1603 - the general installer error code) talks about privileges for SYSTEM on the target drive, but nothing about services.
[Added] But, come to think of it, one might do the driver install first using -Noservice (so that it completes cleanly), then after the reboot, come back and using -Nodrv (which presumably also installs the service, since it installs the UI).
i have same problem with asus desktop (bought 2013 with windows 8) ,on taking to pc repair shop fault was found to be pci express wifi card (chipset incompatible with 1709 update) as i use ethernet i had this removed,but there could be an chipset update.Hope this is of some help to you
Yes, other ancillary peripherals have been known to cause problems with 1709. For example, sound card drivers have also caused problems. But more than a few people have specifically reported issues with the RST drivers that Mister Softie included with 1709. My particular desktop motherboard, and ASUS P6X58D-E does not have WiFi nor have I installed a WiFi card. Since I dealt with the RST drivers and re-applied 1709, I have had exactly one crash over the last two weeks, and it is looking like that one was related to a Creative (Sound Blaster) driver that was in the middle of its install process.
Thanks for Your sharings This, and also the great post from igmikor, helped me to update my install to FCE finaly I was fighting it from quite long time and even had a raid crash meantime. Luckily, I'm using RAID5 so I was able to rebuild it, as only one drive failed.
Now to the point - I'm using very old mobo with P45 Express chipset and from igmikor post and Your sharing I have found, that the _only_ reason of no compatibility between new drivers and old mobos is the registry entry "MessageNumberLimit" set to 80.
I'm using with success right now the newest drivers (126.96.36.1995) and it looks very stable and reliable for me.
Unfortunately, You have no possibility to change registry during FCE upgrade process, because when You even change the registry using recovery command prompt, You have to reboot the machine to apply changes and after that, Windows reverts all changes and boots into last known version. This was mission impossible for me Until I realize, that I'm not following proper path. I forgot the very first step: install RST drivers version 13, which have proper for old mobo MessageNumberLimit value in INF file.
If You, Intel, will be so kind and make a small favor for us, old mobos users, and prepare separate version of RST drivers with correct value of MessageNumberLimit registry entry... We cannot do this by our own, as we can't sign this changes (to be honest, I do not even know how to do this ). Only this small change will make us happy! You don't have to touch SYS files at all - they are good enough. Thanks
Just to be clear, I do not work for Intel. Also, installing drivers that were really intended for *much* later Intel chipsets seems to me to be more risky. We don't really know what the differences are - certainly they are *much* more than just the registry setting you mentioned. I am staying with 188.8.131.522.
I understand that you are having crashes with Windows 10 Fall Creators Update, please accept our apologies for the inconvenience that this could be causing.
In this case I regret to inform you are experiencing compatibility issues between your system components and the OS currently installed with your machine.
The reason that we point this out is because according to Asus's webpage the board that you own has limited support for Windows 10 as you can see on the following link:
If you take a deeper look to the link you will find that the only support given by them on Windows 10 in terms of drivers will be audio drivers, which are basically not related to the issue that you have, meaning that the support will be pretty limited (driver wise)
When it comes about RST, the versions that support Windows 10 will not support the chipset installed on your set up. And on the other hand, the versions of RST that support your chipset will not support Windows 10
On this link you will find the first version of RST (184.108.40.2062) that supported Windows 10 released back in 12/14/2015 that as you can see, will not support your chipset.
(You may need to copy and paste the links provided into a separate tab in case that you have issues when clicking on them)
I strongly recommend you to install an operating system with full support when it comes about drivers and software or to update you system components (hardware) in order to get full support when it comes a newer OS such as Windows 10.
Hope this helps,
No, this reply was not helpful at all. It is the usual corporate speak for "we won't help you because we decided not to".
Here I have an *Intel* product (chipset) that happens to be on an ASUS motherboard that is around five years old, and Intel and Microsoft are getting together, by way of laziness if not outright collusion, to try and convince me I have to buy another machine, never mind that I have successfully run 3 different versions of Intel MSM/RST software under Windows 10. And you are effectively telling me it has a useful life of under six years. Guess what: I already have a pretty good idea of what will and will not work (after spending over 20 hours of my time).
Foisting this issue off on the mobo manufacturer is ridiculous, and also not helpful. They don't write the drivers for this stuff. Intel, Microsoft and their sub-contractors do.
So, either you are not sufficiently informed about what actually works (please refer to the link to the other thread which I posted), or Intel is collaborating with Microsoft to mislead customers. Either one is pretty darn bad. Given this attitude, it is no wonder that Microsoft tries to install drivers that are incompatible, if they are getting this kind of nonsense out of Intel.
Part of the reason that I am posting this thread is so that when other people come across it, they will know that there are solutions, even if Intel does not formally support them (even though they really should).
Telling me that I should either upgrade my hardware or downgrade my OS (which is basically impossible at this point) is not helpful at all.
If Intel cannot be helpful (and apparently they cannot), then don't respond at all, or respond, more accurately that 1) Intel no longer formally supports this chipset and 2) others have found usable workarounds, and provide links to them.
What Intel SHOULD do is get off of their corporate behinds, and provide a supported driver for Windows 10 for these middle-aged chipsets. I will certainly tell you that this experience has soured me on ever using the Intel RAID setup on any future motherboard I may acquire, which also means that I will once again take a good hard look at AMD as an alternative to Intel for my processor as well.
Put that in your heatsink and chew on it for a while.
Intel does not, nor ever did, support Windows 10 on 6 Series or earlier Chipset-based boards nor on 2nd generation Core or earlier processors.
I don't give a rats patootie about what Intel "supports". What matters is what *works* and what Intel and Microsoft really OUGHT to support - among them supporting hardware for a reasonable length of time - and that is a darn sight more than five years.
Let me give folks reading this an education about what it can mean to tell someone that they are supposed to migrate to new hardware and reinstall their operating system.. I bought and installed my machine in fall of 2012. It is still plenty fast: Core i7-950, 12GB. Moving to a new machine would mean expensive new (faster) hardware, but that pales compared to the time spent reinstalling everything, configuring settings, etc.
Here is a list of apps that I use fairly frequently - certainly ALL of them in the last two years:
Applications (ordinary): 3 browsers, Office, Photoshop Elements, iTunes, Audacity, Support for 2 Canon cameras, Quicken, Turbo Tax, Chief Architect Home Designer, eBay TurobLister, Finale (music notation), FitBit, Garmin GPS applications and maps, IrFanView (Scanning), LogiTech Harmony Remote, Punch! Master Landscape Pro, Pinnacle Studio, MIDI-OX, Thunderbird
Applications (engineering): KiCAD (EE CAD), 123d Design (3D modeling for printer), National Instruments LabView support, Ultra Sigma (oscilloscope support), Xilinx FPGA Development software IDE (32 bit and 64 bit), MeshMixer (3D Printing), Cura (3D printing)
Games; NeverWinter Nights, NWN2, Microsoft FSX
Application Development: Visual Studio 2017, Arduino, Android SDK, AcitvePerl, MySQL, Apache, Tortoise SVN, Tortoise GIT, Cygwin
Utilities: Acrobat reader, NovaBackup, PuTTY, APC (UPS), BitTorrent, Cute PDF, BluRay (Cyberlink), GPG (Email encryption), FTP Voyager, IBM Softcopy, NVidia display support, TPLink Switch management, VNC Viewer, Win PCAP, WinZIP, WireShark
If you lost count, that is over *SIXTY* applications. Now, some of them could probably be installed and configured in 30 minutes. Others would liekly take hours to reinstall, find all the important settings and fix them. Last time it took me over 100 hours - and I spent 36 years in IT doing support of mainframes, minis, UNIX, Linux, and PCs from MS-DOS thru Windows from version 1 through 7 [10 came out after I retired].
Now, is this typical? Of course not. But when folks flippantly say that x is not supported, or one ought to go out and buy new hardware, or run an earlier OS (not an option of course), they need to see beyond just the (not trivial) hardware cost to the TOTAL cost of such an effort.
First of all, the x58 chipset was launched in Q4 of 2008. That makes it over 9 years old, not 5. You say you built your system in 2012? That happens to be the year that Intel RETIRED this chipset (and it reached EOL status a year later). This is long before the Windows 10 O/S was released. Why would you expect to see it supported? What is the ROI for Intel to support it on a board that old? There is absolutely none. They should do it just to keep YOU happy? Grow up and start using your brain. No company would do this. No company does this.
N. Scott Pearson, If you cannot actually help, then just don't reply, eh?
What matters to me is when I bought it, not when Intel decided it was passe, and what a reasonable expectation for what was then a pretty high-end CPU and motherboard. I installed Win 7 when I bought it. When I upgraded from Win 7 to Win 10 (and given the Microsoft stance, there was little choice, because if one didn't one was going to lose updates, and have to pay for the upgrade instead of getting it gratis), the upgrade process didn't say *boo* about the hardware not being supported. Nor did the Fall creator's update 1709. It just silently uninstalled my old drivers (and the RST app), and silently installed drivers that simply did not work.
Lots of companies supports lots of products for far longer than the silly computer industry. My NVidia video has supported drivers, thank you very much. So does my RealTek sound chip. Cars. Airplanes. Machine tools. Weapons. And on and on and on. Just because the computer industry (and particularly, the software industry) has its head up its rear end doesn't mean that I am not using my brain or have not, as you say, "grown up".
The ROI for Intel in this case is that, for minimal effort to verify the new code against the older chipsets, they avoid chasing away customers. The ROI for Microsoft is to avoid chasing customers away towards Apple who (partly because of their constrained hardware environment, of course) doesn't saddle people with horribly unstable systems nearly as often as Microsoft does.
As a customer, I don't give a darn about Intel's ROI. I should not have to. I am the customer. I care about *MY* ROI. And having to spend 100+ hours plus upwards of $1,500 to replace my hardware [since I would need to purchase all new, including SSD and drives so that I could keep doing stuff while I migrated] for essentially NO ROI doesn't sit very well with me at all. And I can imagine there are thousands of small businesses that are faced with tese kinds of choices. When I was on Windows 7, the small business that employed my wife was still running on Windows 98.
If you can't actually help, please just don't reply.
The Intel page for 220.127.116.113 is actually vague on support of the X58 / ICH10R chipset. It also does not help that Intel uses vague terms like "5 Series", which though it does not confuse me, is bound to confuse a lot of people. Near as I can tell, the X58 is "5 Series", and as such, the latest release currently on the Intel page that specifically mentions it is 18.104.22.1681.
On the page for 22.214.171.1244 it reads "For Intel Platforms not supported above, visit the RAID version 14.8.0.", which is precisely why I tried 126.96.36.1993.
The page for 188.8.131.523 (the only 14.8 driver available without "digging" through sometimes questionable 3rd-part sites), which did not run at all, and which is what I tried after the 1709 update gave me problems, there is NO information in the release notes to indicate that any older chipset is not supported. And it indicates it supports Windows 10, 32 and 64 bit.
The readme for 184.108.40.2063 indicates it was *designed to provide functionality* for later chipsets, but does NOT say anything about not *working with* earlier chipsets. Indeed, under system requirements, it lists only processors.
The readme for 220.127.116.113, which is what I upgraded to in November, does specifically mention the X58 chipset, but, of course, is not specifically qualified for Win10 (though it was working just fine, thank you very much, until the 1709 Fall Creator's Update - which I suspect, but do not yet know for sure, almost certainly replaced them with a later driver which does not work).
At the very least, it would make sense for Intel driver installations to check and at least warn people they are about to install a driver that is not supposed to work on their platform. If they at least did that, or aborted the install and avoided replacing earlier drivers which *do* support the X58 chipset, then people would not have nearly the problems they are having.
Again, not helpful. And again: nonsense. An installer should at least recognize that there isn't supported hardware there, and not REPLACE the existing drivers, then. From what I have read online there are likely *thousands* of people struggling with this kind of thing. It's just awful. That is a LOT of customers to have systems where the Fall Creators Update silently replaces their drivers with newer ones that cause their system to fail/crash/fail to boot/BSOD/etc.
Let me be very clear on my position,
This is a Support Community. If you have further questions about supported hardware and software, go ahead and ask them. Otherwise, I am going to terminate this conversation.
If you are a moderator of some sort, please do not terminate this thread or prevent me from posting to it. In a week I will try the 1709 Windows 10 Update again, and document exactly what drivers they are installing, what what I did about, so that others who may search on this same issue / platform / chipset here can get some good out of it, because few people are documenting what is happening out in the wild. That was all my purpose ever was. This isn't your thread. It is mine.
And it was never my intent or expectation that Intel would necessarily do anything about my particular situation (though I really think that they should).
Today I again let the Microsoft Update do its thing and install the Fall Creator's Update (FCU), 1709. Fortunately, because I am running Windows 10 X64 PRO, I was able to use group policy to put updates on hold (the other techniques do not work reliably in my experience).
https://www.forbes.com/sites/gordonkelly/2015/08/26/windows-10-how-to-stop-forced-updates/# 521995fa46f6 Windows 10 Hack: 3 Ways To Stop Forced Updates
(Recall that before that I had updated my RST drivers to level 18.104.22.1682, based on the advice I found at:
I checked my driver levels after the install, and the RST drivers remained at 22.214.171.1242. Unfortunately this means I have no information, other than hearsay, about the driver levels the last time I tried. Hearsay indicates that level was likely to have been 126.96.36.1992, from that same post.
Of course, the RST User Interface was (silently) uninstalled again - that was expected.
As a BTW, I had also updated my RealTek audio drivers to the latest version available on the downloads for my ASUS Mobo: 188.8.131.5248
So far, so good. No funkiness during the update. I will wait a few days before I install the UI (using SetupRST -Nodrv), but I expect that everything will likely be just fine.
Updated 2/10/2018. Today (while I let it simmer before installing the latest Microsoft updates), I did the "SetupRST -Nodrv", release 184.108.40.2062 - matching my drivers. The install worked fine; in fact, it noticed that the product had already been installed and did a "repair" install. Seems to be working fine.
Updated 2/13/2018. Remaining updates (2018-01 update, 2018-02 update (this latter one looks to be just a Flash update) and KB4058043 applied. RST drivers were not changed and the user interface was not uninstalled. System booted just fine. I will come back in a few days for what should be a final comment/update.
Update 3/9/2018. I have had a couple of more crashes, but they do not seem to be RAID related. For example, this morning I got another DPC WATCHDOG error. This time it managed to create a dump file. After updating my copy of the Windows SDK, I ran windbg (X64) and loaded the dump file. It very quickly pointed a finger at the driver for my Sound Blaster XFi Platinum card. (A subsequent boot also died, and after a CPU reset, the RAID is into verification, even though the RAID BIOS indicated it should not have needed). Also, after pulling the card to check its part number, and reinserting it, Windows is now claiming it has a "problem". (I won't be documenting that particular adventure here any more - I expect I will probably just remove the card and its software).
Thanks to igmikor I was able to install decent drivers and rst ui again with Windows 10. I was also able to upgrade to 1709 via his method b. This was quite some time ago. My system has been very stable, BUT the 1803 update fails to install seamlessly, just like the 1709 update. I'm wondering if I have to take the same approach as the 1709 update. Has anyone gotten the 1803 update or October update to work?
I agree with cube1us2 that Ms and Intel dropped the ball on us. They should've never let us with x58 upgrade to Windows 10 in the first place if they weren't going to support the chipset. There are still legendary machines out there running this chipset, and to screw us like this doesn't bode well. N. Scott Pearson also irritates the daylights out of me and does no good here. Something about his picture makes it even worst.
My next machine will have a more robust hardware RAID solution and it probably won't come from Intel. There's a chance AMD will get their act together and bring back the chip wars...
Method B (if you got BSOD after restarting PC):
1. Load from working OS_rescue_DVD disk to load OS. You must see all your disks and partitions.
2. Select "Use command shell"
3. Run "regedit"
4. Check "HKEY_LOCAL_MACHINE" key
5. Use "Load Hive" from menu
7. Enter a random_name. For an example: edit_system
8. Edit [HKEY_LOCAL_MACHINE\"random name"\ControlSet001\Enum\PCI\VEN_8086&DEV_2822&SUBSYS_82D41043&REV_00\3&11583659&0&FA\Device Parameters\Interrupt Management\MessageSignaledInterruptProperties]
"MessageNumberLimit" from decimal "80" to "1".
For an example, it may be: [HKEY_LOCAL_MACHINE\edit_system\ControlSet001\Enum\PCI\VEN_8086&DEV_2822&SUBSYS_82D41043&REV_00\3&11583659&0&FA\Device Parameters\Interrupt Management\MessageSignaledInterruptProperties]
Caution! "PCI\VEN_8086&DEV_2822&SUBSYS_82D41043&REV_00\3&11583659&0&FA" this the part of a registry path must be equ...