For me pick and browse seems to be tiny difference with huge impact . Thanks for your speedy reply, after picking the driver, forcing the update and rebooting, my RAID disks where accessible. You made me happy .
Glad to hear things are pretty close to getting totally solved; this thread is probably the <only> place right now that has such good resources on this issue!
I’ve been away on business but next weekend I’ll be back. My plan is to finally find out <exactly> what the update changes and how it causes this issue. I will take snapshots of the all the relevant INFs and registry settings now; install the next cum. 9/13 update, and on the first reboot which we know still works; take the same snapshots. And then of course fix it again
I should have something for this group then - unless it’s completely solved beforehand
Hello Kleini, I’m not sure wheather it has been mentioned or discussed here, but in an other forum I read that Nvidia stopped selling (and this also means earning money with) device driver hardware many years ago. So it’s more or less logical, that support for old hardware will not last forever. On the other hand for me it’s unclear, why MS changed somehow the interface, maybe there would have been an upwards compatible solution, too. My PC now ist at least 8 years old and so I can be happy that even Windows 10 is running. But I would not have upgraded from Windows 7, if these changes had been known in advance and reported as warning by the upgrade monitor. Regards, Rainer
I agree with you, that the owner of old hardware cannot expect, that Microsoft takes care about them, when they develop a new Operating System, but Win10 v1607 is just an Update of Win10 and no new Operating System. For me it is unacceptable, that Microsoft forces the installation of an Update, which automaticly kills the usage of a system, which worked fine until the update and doesn’t care about the affected users.
That’s more or less the same i wrote a couple of weeks ago in the German forum about this topic (there I got the link to this forum). http://answers.microsoft.com/de-de/windo…f4-8d870f772305 I wrote something like today they destroy RAID, tomorrow Sound and the day after tomorrow Graphic.
On the other hand I mean to remember that MS has plans to stay with Windows 10 as a kind of evolutionary OS. But if you live for a very long time then you cannot be always upwards compatible, sometimes you must make a cut to get rid of seldom used code to keep the rest stable and maintainable. I was happy with Windows 7, but a little daemon inside me told me, that I must migrate to the modern Windows 10. In this case I’m happy that you provided a workaround, but it did cost me at least one day, until I found the reason and got the workaround running. This definitely was a absolutely unnecessary waste of time.
seems to found solution with help of NTLite for clean installing Win10 Pro x64 v1607 (German Version) with NO need to break booting while installing and without modifying registry! onto my nForce RAID array (for testing, i degraded my RAID 10 array to two RAID 0 arrays).
I did it this way:
Remove with help of NTLite (according >this< guide) in Win10 v1607 ISO the “in-box” “driver” resp. INF file “nvraid.inf” (Force RAID driver v10.6.0.23) and “scsidev.inf”. Instead insert “new 64bit nForce SATARAID drivers v11.1.0.43 mod+signed by Fernando” (from post #146) AND scsidev.inf from Win 10 v 1511 (see post #184). Burn modified Win10 v1607 ISO to DVD or USB Boot disk (i ckecked both positiv). Boot with modified Windows 10 DVD or USB boot disk. Windows do normally installing without any errors. All necessary re-boots working without problems. Windows Setup detected RAID Arrays disk that come from modified driver. In Win10 v1607 the “new 64bit nForce SATARAID drivers v11.1.0.43 mod+signed by Fernando” are in use without digitally signed, but still working after several reboots.
Nevertheless i changed them to original Nividia WHQL drivers v11.1.0.43 with sucsess.
Unfortunately till now, i am not able to do update my Win 10 Pro v1511 with this modified Win10 v1607 ISO to DVD or USB Boot disk. Update starteted well, but at boot it rolled back to v1511 …
BTW: Maybe we can achieve something at Mircosoft by voting in Windows Feedback to solve the problem by Microsoft…
EDIT by Fernando: Fully quoted, but unneeded post removed (to save space)
I have managed to create an ISO that allows an uninterrupted install of Windows 10 64 Pro. I took the steps that Fernando did and realized that during the bit where I had to edit the registry, that the entries from scsidev.inf were being used
I then went back and modified the Windows 10 ISO further and removed two lines from scsidev.inf referencing Generic SCSI Array Device within the msft section
When I install from this USB Boot drive now I no longer need to make any changes.
When in windows 10 device manager shows Fernando’s modified drivers 11.1.0.43 being used and shows drivers as unsigned.
@SteveyB : Congratulations for having succeeded with the clean installation of Win10 v1607 onto your nForce RAID array without having to "repair" the registry of the freshly installed OS and without getting any "Unaccessable Boot Device" message while rebooting. Furthermore I want to thank you for your detailed report.
The only disadvantage of your solution is, that all the problems may re-appear after the next Windows Update, which contains a newer Build of the Win10 in-box INF file named scsidev.inf. That is why I recommend to test a bootable Win10 v1607 image, where the in-box nForce RAID driver has been replaced by any of my offered mod+signed SATADRIVERS with the name suffix "test3", but without touching the in-box INF file scsidev.inf. My driver variants "test3" do not contain the word "Array", which is obviously the key word for the Win10 hardware detection during the second part of the OS installation to replace the previously installed and properly working mod+signed nForce RAID driver by the "bad driver" scsidev.inf. If this should not work, you may try to remove both in-box "drivers", the nForce RAID driver and the scsidev.inf file.
This message is wrong and caused by the fact, that you haven’t yet imported the "Certificate", which declares the Company Win-RAID CA as "trustworthy".
Good to see that you guys are progressing on this issue. I have a few questions and tips.
- are you saying that Nvidia WHQL drivers are just not working during install, but if the installation finishes, you can install the official driver overwriting the modded one? I guess you force-installed the official one with have disk - manually picked the device?
- if the PNP detection phase is all that’s troubled, you can instead of editing the inf, edit the registry. I know it has been mentioned, but why not do that?
Since NTLite can edit hives that before install (registry page, right-click on the hive and edit), I would suggest the following: – remove the old nvraid, integrate new one, to boot.wim and install.wim – edit in hives where the nvraid.inf (or whatever the main inf of that working official driver is) is being referenced to include the Fernando’s modded INF HWIDs, probably add them to these locations: HKEY_LOCAL_MACHINE\SYSTEM\DriverDatabase\DeviceIds\SCSI* Mimic how the other drivers are being referenced. Same applies to remove scsidev.inf from the game, to not take precedence, remove it from the IDs right list you want it excluded from.
I’m willing to automate this if you confirm it’s working, as it’s a pain to do it manually taking ownerships. Easiest solution would be to make a REG file and apply it directly to the image (NTLite - Registry page), but I need to finish the auto-take ownership of referenced keys in this case (and return the original owner after editing), but it’s an easy option that will work for automating the process after it has been confirmed needed.
- regarding the rollback, was that from running the KB directly (WU included) or you start setup.exe from a full patched ISO? More about it here. Even though rollbacks can happen for many reasons, you can check the %location%\Panther\setuperr.log for details after the rollback, feel free to attach the zipped log here (setupact.log even better). If you run WU/Manual KB then %location is in C:\Windows, for setup.exe it’s in C:$WINDOWS.~BT
- to reduce the chance of Windows returning some other driver, you can disable automatic WU driver updating in NTLite - Config - Local Machine - "Automatically update device drivers and icons" and "Update device drivers" tweaks. Disclaimer, no guarantees, keep that backup ready on each Windows update.
@nuhi : Thanks for your very useful input, your tips and your willingness to help the affected nForce RAID users with an updated version of NTLite, which will make the customization of the Win10 image much easier for them.
According to the reports I have seen the textmode phase of the Win10 v1607 installation is affected as well. The in-box nForce RAID driver obviously doesn’t detect the nForce RAID array at the beginning of the Win10 v1607 installation (contrary to the previous Win10 versions).
According to the reports I have seen the textmode phase of the Win10 v1607 installation is affected as well. The in-box nForce RAID driver obviously doesn’t detect the nForce RAID array at the beginning of the Win10 v1607 installation (contrary to the previous Win10 versions).
Thank you.
A bit more questions to clarify: - so Win10 1607 doesn’t even boot to the part for loading drivers manually? I guess it BSODs or something? - How about when people remove the offending drivers from boot.wim, does it then reach the driver loading phase? - And did anyone try to integrate the missing reg/hwid entries to the boot.wim, with the accompanying working signed driver?
You are right. I force-installed the official Nividia WHQL drivers v11.1.0.43 with "have disk" from USB-Stick. (Surprisingly toi me, they are accepted…)
Because it seems much easier to me. I did not edit the inf-Files, just use existing files. I´m untrained in editing registry, especially in "load hives".
Wich new "nvraid" you mean?
Thanks for your offer. Instead untrained in editing registry, i will try, as soon as possible.
I started setup.exe from in described way patched WinPro10 1607 ISO (DVD) inside Windows 10 1511.
Thanks for tips. I will try and attach the zipped log here.
According to what I have read it boots fine until the point, where the user has to decide where to get the OS installed, but the Setup doesn’t show the existing nForce RAID array. Even a manually loading of my mod+signed drivers doesn’t help. My comment: The Windows Setup obviously doesn’t accept any not WHQL certified driver as long as it finds an inbox driver with matching HardwareIDs.
One of the testers had used the Win10 v1607 ISO file, where I had removed the SCSIDEV.INF file from the BOOT.WIM and INSTALL.WIM. As far as I remember his report, the existing nForce RAID array still hasn’t been detected by the Setup. My comment: This test result has not been expected by me and is not easy to understand.
@Nvidiapaddel , by nvraid I meant NVidia RAID driver, the nvraid.inf is the filename. There is one in Windows, and the other one you are integrating, IF the filename is the same, unimportant. OK, thanks for the info, will see what can be done.
@Fernando , was there a chance setup to accept loading any non-signed drivers, if no alternative? Btw note to everyone, if I haven’t sent this already, Win10 1607 does not allow non-MS signed drivers, let along unsigned ones automatically. Point is if you use UEFI, be sure to disable SecureBoot while testing drivers, I actually needed to do this for my legit soundcard driver which was usually working.
Two things on my mind for now: - dream option would be to allow ID editing on drivers registry entries after install, unless the whole registry is just to speed up reading of available INFs and once you start installing it again goes from the INF only. - I think I saw some leftovers in the registry ID lists, from the removed nvraid.inf. Not sure if that even matters as Windows can continue to the next candidate.
I’ll start with better cleanup in a few days, need to finish this version update then I have some time. This starts to look like the old times when we needed to do much more for the drivers to load in textmode. But don’t give up, if it works when manually forced, it’s just matter of seeing how to hardcode that in the registry.
Will be onto it in a few days, this is interesting.
@edv.kleini , check for example here on how to take registry ownership so you can apply keys to those areas.
All I know defenitively until now is, that the nForce SATARAID drivers, which have been modded and signed by me, were accepted by the Win10 v1607 Setup, if a) the related INF file contains the required HardwareIDs (Note: The requirements obviously have been recently changed by Microsoft. That is why not even the in-box nForce RAID driver v10.6.0.23 is accepted anymore.), b) they were integrated into the related image and c) the in-box nForce RAID driver had been removed from the image.
@all nForce RAID testers: Recently I have created a lot of differently mod+signed test variants of the nForce SATARAID drivers v11.1.0.43 and v9.99.09 and uploaded them to >this< OneDrive folder, which is open for the public. Additionally I have added my previously mod+signed nForce SATARAID drivers v11.1.0.43 and vv9.99.09, which I had attached to the posts #146 (v11.1.0.43) resp. post #154 (v9.99.09). They are named "new 32/64bit nForce SATARAID drivers".
It would be very helpful, if anyone would be able to to boot off an orginal Win10 v1607 image and to load the drivers with the matching architecture (32/64bit), when the Setup asks you where the OS shall be installed. For our further steps we need to know, which one of them will be accepted by the Setup and show the existing nForce RAID array. Note: If you stop the OS installation at this point (after having realized, if the driver has been accepted by the Win10 v1607 Setup), nothing will be really installed onto your system! So you can simply continue the test without touching any of your previously existing data.
CurrentControlset\enum is current system hardware info read from the hardware, it should not be changed manually. What we need is connect drivers to have the IDs that are in the enum. See here for more info. In other words that is what Windows reads from hardware, not the drivers, on each reboot. If I’m mistaken feel free to correct me.
I would place my bets to this key: HKEY_LOCAL_MACHINE\SYSTEM\DriverDatabase\DeviceIds\SCSI
You can easily edit image hives, both in boot.wim and install.wim with NTLite - Registry page. If I had your machine, I would check on the working compatible OS like 1511 all references in the registry to the working driver and make a REG out of it, then edit that into the image hives. NTLite won’t auto-take ownership of the reg, so do that to the root keys before adding/integrating your REG file with changes.
Let me know how it goes or maybe you have a better approach.
@edv.kleini : Thanks for having tested the ISO file, which had been customized by me. It is a pity, that you got the "Unaccessable Boot Device" message after the reboot again, although I had inserted an nForce SATARAID driver, whose INF file doesn’t contain the key word "Array".
Just for the record: The Win10 in-box nForce RAID driver has been compiled by NVIDIA and not by Microsoft.
That is evident, because otherwise the nForce RAID users wouldn’t have run into their problems, but the Win10 in-box NVIDIA nForce RAID driver itself has not been changed resp. customized (neither by NVIDIA nor by Microsoft). What undoubtedly has been changed by Microsoft is the Hardware Detection regarding SCSI Devices and the handling of RAID Array Members (HDDs/SSDs). Note: There are a lot of chipset manufacturers besides NVIDIA, which are/were manufacturing RAID Controllers, but only the members of a NVIDIA nForce RAID Array need a driver themselves (otherwise the array will not be detected and managed by Windows). The RAID Controllers of all other companies (Intel, AMD JMicron, Marvell etc.) are able to manage the RAID Array and its members without the need to install the RAID driver separately for all of them. That is the reason why only nForce RAID users are affected by the changes, which were recently done by Microsoft.
Can you please mod and sign the Legacy v6.99 Raid RAID drivers to work with Aniversary update? I recive a lot of bluescreens (or pc freeze) on nforce MCP55 chipset with v9 and v11.