@ all nForce RAID users, whose system drive is within the RAID array:
Here is my interim report about the test results:
Meanwhile I have given the requested download links to at least 5 Forum members, who were willing to try a fresh install of a customized Win10 v1607 image onto their nForce RAID array. A big thankyou goes to them for having taken the time for such a test.
Until now I got only feedback from the user SteveyB, who reported, that he was not able to get Win10 v1607 installed this way, because the OS Setup did not detect the existing nForce RAID array, not even after having loaded the WHQL certified nForce SATARAID driver v11.1.0.43, which is part of my “Latest nForce Driverpacks v10.4”.
This test result may indicate, that the presence of the in-box INF file named scsidev.inf (latest, but “bad” version: v10.0.14393.0) is absolutely required for the detection of any RAID array.
Speculation:
If that should be verified by the other testers, I am rather unsure, whether it is possible at all to solve the problem permanently by customizing the Win10 v1607 image. A replacement of the “bad” Win10 in-box scsidev.inf version by an older and working one from the previous Win10 version may be an option to get Win10 v1607 clean installed onto an existing nForce RAID array, but there is a big risk to get an unbootable system again after the installation of Microsoft’s next “Cumulative Update”.
Another option would be to get a digital signature from Microsoft for the mod+signed drivers, which I have attached to the post #146, but this would not only cost a lot of money, but may require an explicit permission given by NVIDIA to alter their original INF files.
EDIT:
To find out the exact reason for the “SCSI Array Device” issue while updating Win10 on an nForce RAID array, I need the file named scsidev.inf from any Win10 x64 installation, which hasn’t yet been updated to v1607.
The related file can be found, if you open the folder C:\Windows\System32\DriverStore\FileRepository and search for the subfolder, whose name begins with “scsidev.inf_amd64”.
Please compress the file as a *.zip or *.rar archive and attach it to your post.
Thanks in advance!
Kinda why I’m working on reinstalling a fresh copy of Win7 on my system and staying there.
Hi Fernando!!!
I’m of course brand new to this forum, but I absolutely found it due to this issue which we all agree is horrible. And even more horrible that we all know neither M$ nor NVIDIA will probably ever fix it.
So unfortunately I’m in the “boot drive” scenario as I only have one disk (STRIPE 2x150GB) which is the RAID array and after the KB update and one reboot (didn’t install Anniversary; still on build 15**), I now get the famous INACCESSIBLE_BOOT_DEVICE BSOD.
However - I might be in a bit of a unique position because I am dual-booting with 7, and my 7 partition is still doing just fine. What this means is that I have full access to the Windows10 partition, and I’ve already started messing with various .INF & even Registry changes (I can mount the 10 hives in 7), so far to no help. But I think I may be much closer after reading how much good info is here. Note that even if you don’t dual-boot, Recovery mode will also let you access files & mount hives.
Based on everything you’ve written, it in theory <should> be possible to edit the SYSTEM registry and/or .INFs in such a way as to fix this - the proof being that it <does> work on a new install. The problem of course is knowing what changes will actually do the trick. I’ve been trying to research exactly what/where the Windows boot process looks for when it tries to load a driver but I haven’t been able to get definite answers. I absolutely want to try to fix this “in-place”, without wiping my partition, as I take this as a challenge and if we can figure out the in-place workaround it will help many others.
So far I’ve added some hardware IDs to some .INFs and into the registry (ENUM key) but without any luck. But I haven’t yet tried fully “replacing”’ registry-wise, the generic SCSI entries (ie simulating actually “installing” the real nvraid drivers.) Based on what you know so far, do you think I have any chance of accomplishing this and if so, do you have any recommendations?
Thank you in advance, Justin
Hi Fernando,
I rolled back my windows 10 to previous version. I could do it since my raid array, nForce 630, is not used for windows.
This way, i have copied the folder/file you have requested. It´s attached.
Let me know if that helps.
@ENAJonas :
Hello Justin,
welcome at Win-RAID Forum and thanks for your contribution!
What you have done is very courageous, but I doubt, that you will succeed this way. It is much better and safer to solve a driver problem from within the affected OS without touching its registry.
Until now I am still pretty sure, that we will find a way to solve the Windows Update problem without the need of manipulating the OS registry.
@sedilson :
Welcome at Win-RAID Forum and thank you very much for having posted the requested scsidev.inf file v10.0.10586.0 dated 06/21/2006 (the year number entered by Microsoft is absolutely misleading!).
After having compared this older INF file with the "Anniversary Update" one v10.0.14393.0 dated 08/31/2006 (still wrong year number!), I found these interesting differences:
1. Difference: (left Pic: v10.0.10586.0, right Pic: v10.0.14393.0)
2. Difference: (left Pic: v10.0.10586.0, right Pic: v10.0.14393.0)
As you can see, it is the older file named scsidev.inf, which contains the entries regarding the "Generic SCSI Array" and not the latest scsidev.inf version, which is within the "Anniversary Update" of Win10.
This lets me think, that Microsoft may have already corrected their earlier mistake, when they compiled the "final" Win10 v1607 Build v10.0.14393.0.
My conclusion:
The "bad" file, which makes the nForce RAID array unaccessable, seems to be the scsidev.inf v10.0.10586.0 and not the v10.0.14393.0 one.
Consequences:
Maybe all the nForce RAID problems can be solved by a clean install of Win10 v1607 and loading the appropriate nForce SATARAID drivers.
Update:
Our Forum member narf just has given me the information, that he already tried a clean install of the Win10 "Anniversary Update" onto his nForce RAID array, but the installation failed, because the Win10 Setup was not able to detect the nForce RAID array, not even after having loaded the WHQL certified nForce SATARAID driver v11.1.0.43.
So we have to continue our search for a solution of the current nForce RAID problem for Win10 users.
Kind regards
Dieter (alias Fernando)
Hello all & Fernando —
– NEVER – give up!!! After editing the SYSTEM registry & .INF files, I am back in to Windows10, <with> the update properly installed. All done in-place & with an array as my boot drive!! I’ll post details tomorrow to both this & the MS Answers thread I started. Boy did I learn a lot!!!
Justin
That is great - congratulations!
We are curious about how you managed it.
Sorry for the delay. So what seems to need to be done for non-bootable systems:
- Boot into Recovery Mode. If you don’t dual-boot or otherwise can’t get into the F8 Options menu, you’ll need to boot from Win10 DVD and start Recovery Mode from there.
- Open the Command Prompt in Recovery Mode.
- Find the drive letter (?
for your Windows 10 partition. Note that you’ll have to check for this; the drive letters in Recovery Mode are not the usual ones you’re used to. It’s definitely <not> the default drive “X:” (X is the Recovery partition in RAM.)
- Run Notepad.
- Open ?:\Windows\INF\nvraid.inf
- Add all the Hardware IDs already discussed to the proper sections in the proper way. The ones that make this work are likely the ones starting with “Array_" as those are all missing initially.
- Delete/Rename ?:\Windows\INF\nvraid.pnf if it exists.
- Run Regedit.
- The SYSTEM registry currently displayed is just a temporary Recovery Mode one! You must mount the real one from “?:\Windows\System32\config\SYSTEM”. Mount it as something like “TEMP” under HKLM.
- Navigate to TEMP<your current ControlSet>\Enum\SCSI<“Array&Ven_NVIDIA&Prod_Raid_Disk” or something similar><DeviceID>
- (Your Current Control Set can be seen by checking the “Select” key)
- For every device under “Array&Ven_NVIDIA&Prod_Raid_Disk” (there will be one for each HDD in the array), add all the missing Hardware IDs in the proper way (one string per line) to the HardwareID keys.
- Navigate to TEMP\DriverDatabase\DeviceIds\SCSI.
- You will see the layout here. What you have to do is create keys with the missing HardwareIDs - again the 3 "Array_” are the important ones. The Key name is the HardwareID, the value name is “nvraid.inf” as a BINARY value, and the binary data is “01 ff 00 00”.
- Unmount the hive properly (click on TEMP, File menu…Unmount hive.)
- If the .INF and Registry are properly modified, then the next boot should now just work. No need to disable Driver Signing. Subsequent updates should also be fine.
If anyone has any questions on this, please don’t hesitate to let me know & I hope this helps,
Justin
@ENAJonas :
Thank you very much for having elaborated and posted a method, which hopefully will help Win10 users, whose system drive is within the nForce RAID system and who got an unbootable system after having executed a recent "Cumulative" Win10 update.
Because I have already done rather similar tests with my formerly used nForce4 RAID system, I know how hard your work has been. It is admirable, that you didn’t give up your plans to find a solution despite all problems you ran into (and my doubts, that you will succeed this way).
Important remark:
The file named "nvraid.inf" is the information file for the Win10 in-box NVIDIA nForce SATARAID driver nvraid.sys v10.6.0.23 dated 09/23/2013. So any modification of that INF file will only be helpful, if the onboard NVIDIA nForce RAID Controller and nForce RAID Devices were using the DEFAULT nForce RAID driver v10.6.0.23 just before the array became unaccessable.
NForce RAID users, who were running any other NVIDIA nForce SATARAID driver, will have to customize the recently in-use specific INF file. This file is within the <SYSTEM DRIVE LETTER>:\Windows\INF folder as well, but will not be found easily, because the INF files of all installed drivers are renamed by the OS and stored within the INF folder as "oem1.inf", "oem2.inf", "oem3.inf" and so on.
As a consequence it will be a good idea to find out the exact INF file name of the currently in-use NVIDIA nForce RAID driver before starting any "Cumulative" Win10 update. This can be done by opening the INF files named oemxx.inf ("xx" stands for any number from 1 up), which are listed within the C:\Windows\INF directory, by using the Windows Editor (notepad.exe).
@ENAJonas / @Fernando ,
This is really good news. I currently have a completely wiped system - needs fresh installation. I can see a way forward by installing from my 1511 (November 2015) WIN 10 USB Install image and then applying this fix. This USB boot sees my Raid array on installation.
But one question - My latest 1607 WIN 10 USB boot fails to see the NVRAID drives on installation. Could I amend the latest WIN10 ISO, similar to your instructions in some way to make it work with a fresh installation ?
Thanks for all your effort and help!
@SteveyB :
Welcome at Win-RAID Forum!
AFAIK ENAJonas’s procedure only works for nForce RAID systems, where the Windows Update failed with an unbootable system. A previously completed Win10 install is obviously required within the RAID array.
If I am right, there is still no solution available for nForce users, who want to do a clean install of Win10 v1607 onto their nForce RAID array. Either the in-box nvraid.inf or the in-box scsidev.inf has to be customized, but I don’t yet know how to get a modded driver being accepted by the Win10 Setup.
Regards
Dieter (alias Fernando)
That’s a great point Fernando regarding the customized drivers; I should have mentioned that.
To find out if indeed you are using the stock nvraid.inf vs. an oem*.inf, you can see the INF name by mounting the registry and navigating to TEMP<MyControlSet>\Services\nvraid, and checking the value on the “Owner” key.
With regard to modding a fresh Anniversay install, yes that will probably be more complex due to the enforced Driver Signing that seems to be very sensitive. Otherwise it should just be a matter of somehow finding & modding the nvraid.inf which is probably buried deep in some .CAB or in install.wim knowing MS, so the much better bet is to use Fernando’s driver which should have all the IDs already. But disabling the driver signing seems to be something we’ll have to figure out; I’ll start taking a look at that.
Justin
@ all nForce RAID users, who want to test a clean install of the Win10 x64 Pro “Anniversary Update” onto their nForce RAID array:
Meanwhile I have created a freshly customized ISO file of Win10 x64 Pro EN-US v1607 by using the latest NTLite version. The source ISO file was the original MS one, which had downloaded from the Microsoft Server.
This is what I have done:
- Added to BOOT.WIM and INSTALL.WIM:
- “new 64bit nForce SATARAID drivers v11.1.0.43 mod+signed by Fernando” (identical with the driver, which I had attached to post #146)
- Changed:
- nothing!
- Removed:
- nothing!
The integration of the driver went flawlessly. What I do not yet know is, whether the OS Setup will accept and use it.
Interested users may send me a PM and I will give them the download link to the related ISO file.
If you want to customize the ISO file yourself by using another source file (other OS architecture/platform/language), it should be no problem to do it according >this< guide by using the free version of NTLite.
Please report your test result into this thread.
Thanks in advance!
Hi,
I am struggling to get ENAJonas fix to work - it’s no doubt something I am doing incorrectly. I think the main issue I have is- what are the Hardware IDs I should be adding to all the files?
My device is showing in device manager as NVIDIA nForce RAID Controller
Under Disk Drives my device is named NVIDIA STRIPE 1.81t
The Hardware IDs listed against NVIDIA STRIPE 1.81T properties are -
SCSI\DISK____NVIDIA__STRIPE_____1.81T
GenDisk
Is this the right Hardware IDs?
I updated the .inf and the Registry hive (SYSTEM) with no problems with these values. I am currently sat on 1511 with the update that breaks configuration to Inaccessible_Boot_Device
Cheers,
Steve.
No, the HardwareIDs have nothing to do with the name of your nForce RAID array, which was given by you or the MediaShield utility during its creation.
According to my knowledge these should be the complete HardwareID entries for the "NVIDIA(R) nForce RAID Devices" within the nvrd32.inf resp. nvrd64.inf files:
2
3
4
5
6
7
%NVRAID_DESC%=nvraid,SCSI\NVIDIA__Raid_Disk________
%NVRAID_DESC%=nvraid,SCSI\__NVIDIA_______Raid_Disk
%NVRAID_DESC%=nvraid,SCSI\__NVIDIA_______Raid_Disk_
%NVRAID_DESC%=nvraid,__NVIDIA_______Raid_Disk_
%NVRAID_DESC%=nvraid,SCSI\NVIDIA__Raid_Disk_20_____
%NVRAID_DESC%=nvraid,SCSI\__NVIDIA____Raid_Disk_20
%NVRAID_DESC%=nvraid,__NVIDIA____Raid_Disk_20_
Ok - Thought I had tried those as well… will give it another go and double check all the files.
Thanks,
Steve.
@Steve & Fernando,
I think I see two issues here. One is that for surer those are not all the Hardware IDs. There are 3 beginning with “Array” that are the key to this; those need to be added to your integrated driver as well Fernando. I’ll post the key missing ones tonight when I get back to my system.
The other issue is that Steve you’re not updating the right driver in the registry. There are 4 parts to the RAID Config - the RAID Bus Controller, which uses nvraid.sys, the “Devices” aka members aka HDDs, that also use nvraid.sys, the SATA Controller for the HDDs (nvstor.sys), and then the actual volume presented to Windows, which is just a standard Disk (disk.sys). The only ones with the issue (and for which the hardware IDs apply) are the “Devices” as Fernando mentions. They are usually listed under SCSI key as well, but I’ve seen instances where they are actually listed under “IDE” (since they are physical drives). It is precisely these devices that nvidia marks as Hidden so they will never show up in DM unless “Show Hidden Devices” is enabled. The names of the devices are “nVIDIA nFORCE RAID Device”.
I am not sure, whether you are right regarding this point.
These are my arguments:
- The word "Array" has never been within the HardwareIDs of the "NVIDIA nForce RAID Devices", but within the HardwareIDs of the "Generic SCSI Array Devices" (which we don’t want to get listed within the Device Manager).
- Since Win10 v1607 (Build 14393.0) the in-box "driver" named scsidev.inf doesn’t contain anymore an entry "Generic SCSI Array Device". That is why such device cannot be listed anymore within the Device Manager after the install of Win10 v1607 ("Anniversary Update").
- The problem of the update to resp. the clean install of Win10 v1607 is, that the HardwareIDs of the "NVIDIA(R) nForce RAID Devices", which are detected by the updated Win10 hardware detection routine, are not completely listed within NVIDIA’s officially released nForce SATARAID drivers (inclusive the Win10 in-box one).
- The simple installation of my mod+signed nForce SATARAID drivers v11.1.0.43 (attached to post #146), where I had just added the missing HardwareIDs, obviousy solved the problem for all nForce users, whose nForce RAID array was outside the system drive. These mod+signed drivers do not have the word "Array" within the INF file.
Hello again,
Please see attached screenshot of Reg & DM; I think this sums this all up pretty well. I compared this to my Windows7 install, and for sure the “Array*” entries are the ones required. Somehow, and I don’t think any of us are sure of the ordering of this, the Win10 update (& Anniversary Edition) either deleted these values from the .INF (& therefore registry on the initial reboot), or the updated hardware detection routine changed by the AU is now <looking for> the Array* pre-pended to the actual Hardware ID, when it wasn’t doing so before. Either way it once again requires the “Array*” to be there or it won’t find the device. I did some research on SCSI device IDs, and the “Array*” name pre-pending is <NOT> actually stored and reported from the Hardware itself as the Device ID hard-coded in the firmware…it is <added> by the SCSI standard (software) at some later stage to identify the type of SCSI device (there is also “Processor*”, “cdrom*”, “disk*”, “Enclosure*”, etc.) The “real” SCSI ID is just the part <after> the “Array*”. But to the Windows kernel, it doesn’t really care and just treats the whole thing beginning with Array* as just another Device ID that it has to match <in full.>
The screenshot shows nicely the 4 components and how they relate to each other. On the physical side you have the SATA controller and the two “devices” aka HDDs (you’ll maybe have more of these depending on how your array is physically implemented but you’ll always have at least 2.) On the logical side you have the RAID bus controller and the RAID volume (“disk”) itself. Looking at the Properties of the “Device”, you can see the Hardware IDs listed. One of the ones in the list, I am 100% positive, is the one that makes this work, and I’m 99% positive that it’s the first one in the list. In the Registry I’ve opened the ENUM key which is where these Hardware IDs are stored. I actually don’t think that changing the .INF or the DeviceIDs key really mattered, but I wanted to be sure and update everything I could to be safe. The one thing that <must> happen is that these Hardware IDs must be added to the HardwareID under the ENUM key for the proper devices as shown, <not> on the disk device that’s below, and <not> on the RAID Bus Controller (which is in ACPI key), and <not> on the SATA Controller (in the PCI key).
I hope this helps just a bit more,
Steve please let us know how it goes,
Justin
@ENAJonas , Interesting stuff here…great work! My Hardware IDs are the same as those shown in the above screenshot:
2
3
4
5
6
SCSI\Array__NVIDIA_______Raid_Disk____
SCSI\Array__NVIDIA_______Raid_Disk
SCSI\Array__NVIDIA
SCSI\__NVIDIA_______Raid_Disk_
__NVIDIA_______Raid_Disk_
ScsiArray
@Fernando , I notice that the v9.99 drivers using, do not have all of those IDs, but the latest v11.1 .inf do have them all. I checked the v9.99 latest (8/24) and previous (8/19); neither have them all. I was thinking to check those registry settings after the August Cumulative Update first reboot, to see if ENAJonas' changes might work after the 2nd reboot...
Also, have you guys seen this:
https://blogs.msdn.microsoft.com/windows...0-version-1607/