Installing W10 from 16 GB USB.

[johnhc]

I have an ASRock X399 board that I created a RAID0 and need to install the drivers.  There is an order requirement for the drivers, so I have been unsuccessful in injecting the drivers.  I have tried using Rufus to create a USB stick and as long as I use an 8 GB stick, all is fine - the drivers install fine (using "Load Driver" on "...where do want to install...") and I can see my RAID.  If I use a 16 GB stick (required for my large Unattended install) and the drivers appear to install OK, but I still see the individual drives and not the RAID.  I have posted on the TechNet forum with one reply that did not help.  Can anyone suggest a solution of source of a solution?  I do have an open ticket with AMD but no useful reply so far - maybe after the holidays.  Thanks much for you time.  Enjoy, John.

[HarryTri]

It doesn't seem probable that the stick's size make the difference, are you sure that the drivers installing mechanism is the same between the two sticks?

[johnhc]

HarryTri, thanks for your reply.  I agree that this does not seem probable, but I have done a lot of testing and I have no other explanation.  If I use Rufus to write a small W10 ISO on an 8 GB USB, the drivers load fine.  If I use Rufus to write the same ISO on a 16 GB USB stick, it fails to load the drivers so I can see the RAID array.  The brand of stick does not matter - have tried several.  Thanks and enjoy, John.

[jaclaz]

What is the "structure" of the USB?

I mean does it still contain the .iso or it is "flat" or "semi-flat"?

There are/were some issues with the placing of files in large .iso's, but that happened on smaller sizes (like 4 Gb) and were limited to files that were accessed by NTLDR or BOOTMGR, if I recall correctly, and in any case that would provoke a "a file is missing" or "cannot access file", kind of issue, not a "working build" overstepping a driver installation. 

Depending on how exactly the stick is made you could try making a partitioned stick with two smaller partitions, and use a mountpoint in the first for the second, but it simply doesn't sound a good idea.

Maybe - just maybe - something that is happening is that the larger stick *sommehow* is mapped differently by BIOS/UEFI, and it changes disk order?

If you boot to the install PE and get to command line (Shift+F10) can you run Diskpart from the two sticks and see if there is any difference?

jaclaz

[johnhc]

Thanks, jaclaz.  Rufus extracts the ISO and copies the files/folders to the USB, so it is a flat.  I have installed many times from a flat, but using a HDD or SDD.  The files are the same.  I have used FAT32 and NTFS file systems on the USB.  Both work on the 8 GB USB.  The NTFS file system results in two partitions and that works fine also.  I usually use WinPE to start my unattended install from a HDD or SDD.  I do use Diskpart but I do not understand what differences you want me to look for.  I suspect there are none except size.  Even when I could not install the RAID drivers I am able to install Windows using the AutoUnattended.xml on the USB.  Thanks and enjoy, John.

[jaclaz]

I either don't know what to look at exactly, just checking if any difference is spotted.

More like "excluding the impossible",

There is normally no filesystem difference in a 8 Gb vs. 16 Gb size (re: cluster size),

What it could be is some (if not bug) "peculiarity" of the BIOS/UEFI (or even of the OS), it is not uncommon that there are "arbitrarily" behaviours conneceted to "size", though I don't remember any in that particular size range.

A typical one is different behaviour when the USB stick is set as "removable" (like 99% of sticks are) or "fixed" (like say 1% of sticks and 100% of hard disks) or something connected to the CHS limit (nowadays *nothing* uses or should use CHS anymore, still 1024*255*63*512=8,422,686,720 is the limit of CHS, and it is possible that the 8 Gb stick is within it whilst the 16 Gb is definitely beyond it) and even if in theory it should make no difference whatsoever, in some cases it happened that different disk order was attributed connected to these..,

It could also be the drivers .inf files that expect the RAID to be (say) first disk or whatever, including some "peculiar side apps that - for whatever reasons - cannot "reach" a given LBA.

Another experiment you can do is the following:

1) prepare the 8Gb stick
2) verify that it installs drivers
3) make a "forensic sound" image of it (using dd or dsfo, etc,)
4) prepare the 16 Gb stick
5) make a "forensic sound" image of it (using dd or dsfo, etc,)
6) deploy the 8 Gb image "as is" on the 16 GB stick
7) verify that it installs drivers like the 8 Gb did

If it does:
8) extend the filesystem to cover the whole 16 Gb
9) copy (at filesystem level, i.e using copy, Xcopy or similar) to it the contents of the 16 Gb image, overwriting existing files

This way the LBA address of the files already existing on the 8Gb stick will (should) remain the same.

jaclaz

[johnhc]

Thanks again, jaclaz.  The author of Rufus put me on the 'removable' bit and right now I am trying to find a USB with it flipped.  It seems a 'fixed' USB stick is required for WindowsToGo.   It is not an easy subject to search.  I have asked SanDisk for help.  I am not familiar "forensic sound" image, but will look at it.  Thanks again and enjoy, John.

[jaclaz]

3 hours ago, johnhc said:

Thanks again, jaclaz.  The author of Rufus put me on the 'removable' bit and right now I am trying to find a USB with it flipped.  It seems a 'fixed' USB stick is required for WindowsToGo.   It is not an easy subject to search.  I have asked SanDisk for help.  I am not familiar "forensic sound" image, but will look at it.  Thanks again and enjoy, John.

Well it is not particularly difficult, as there is an (easy) workaround in the form of one of the filter drivers that "flip the bit" in software.

It has to be seen if the fiter driver in the PE is working in your specific case, though.

More or less Sandisk is the ONLY make/brand for which a "set fixed/removable" "Manufacturer Tool" is NOT available (all the others usually are, though some of these tools are easy-peasy while some other ones are so little documented and "tricky" to make it advisable to avoid them).

There are basically three available drivers:

1) good ol' cfadisk.sys
2) Anton Bassov's dummydisk.sys
3) the "new" kid on the block, Karyonix's  diskmod.sys

They all work at least up to 7, but I believe you are dealing with 64 bit, and besides being the most recent one, diskmod.sys comesalso as a 64 bit and has a few added capabilities, so if I were you I would try it:

http://reboot.pro/topic/9461-page-file-in-usb-hard-disk/

About flipping the bit in hardware, the reference page is this one (Russian, use google translate or similar):

http://www.usbdev.ru/

 

A "forensic sound" image is nothing but a byte-by-byte copy of a a "disk like" device contents (much like a .iso image is the image of a CD or DVD media), in Linux the usual tool is dd, in Windows there are many similar tools, including a good dd for windows, the issue with Windows 10 in some cases may be permissions, the most compact one is dsfo/dsfi (part of the dsfok toolkit):

http://members.ozemail.com.au/~nulifetv/freezip/freeware/index.html

not the faster one, if you prefer a GUI (and faster) one, you can go for Clonedisk:

http://reboot.pro/topic/8480-clonedisk/

http://labalec.fr/erwan/?page_id=42

but *anything* that can make an image of a disk and deploy it to another one would do for the experiment.

jaclaz

 

[cdob]

On 30.12.2017 at 10:11 PM, johnhc said:

If I use Rufus to write a small W10 ISO on an 8 GB USB, the drivers load fine.  If I use Rufus to write the same ISO on a 16 GB USB stick, it fails to load the drivers so I can see the RAID array.

This is  a nice miracle.

Can you clarify?

Do you use a X399 Taichi? X399 Taichi

Did you update the BIOS (UEFI firmware)?
Which RAID driver version do you use?

Do you use BIOS or UEFI mode at the 8 GB USB stick?
Do you use BIOS or UEFI mode at the 16 GB USB stick?

Which Windows version do you use?
1709 supports several partitions at a removable device.
The removable bit is not importand anymore.

Which max file size do you use? Does it fit at FAT32?

As far as I know, Rufus use a special MBR code. Or a special Efi NTFS driver.
May this interfere with RAID? I don't know.
Just to crosscheck: what happens if you build the USB stick with diskpart and xcopy?

[johnhc]

Thanks, jaclaz.  I am cogitating all of this and hoping to hear from SanDisk so I can buy a USB with the Removable bit flipped.

Thanks, cdob.  I am using the ASRock Fatal1ty X399 Professional Gaming running BIOS 2.00.  Please see here for details of my build.  I am misterj.  Everything I do I do with CSM disabled, GPT and UEFI.  With Rufus, I use FAT32 if my Install.wim file is small enough, then NTFS - makes no difference.   I always am using the latest W10 (1709.16299.125 right now, probably .....98 on my last test.)  As long as I boot my 16 GB stick, the RAID drivers do not load properly, even if the stick contains W10 created by Media Creation Tool - so no me involved and no Rufus involved just MS.  I have not tried diskpart and xcopy but have tried Oscdimg which is what the WinPE maker uses.  If I use a 8 GB stick and Rufus all is fine.  I am using the ASRock RAID drivers from the ASRock DL page.   There are two .zip files but the drivers are identical inside.  A bad thing about these drivers is a certain installation order is required.  I have tried to inject the RAID drivers, but no-go (works for the Aquantia and other drivers.)  On past AMD builds injecting drivers worked fine and I could skip this silly "Load Driver" step.  I hope you will drop by the ASRock forum and contribute.  I have written some RAID instructions and am in a conversation with AMD Support to try to understand more and get them to remove the driver install order requirement.  I have tried the AMD drivers and I suspect they will work at least as well as the ASRock ones, but not cure my install problem.  ASRock modifies the AMD drivers but says they have not (the signature is not right and Secure Boot cannot be used.)  I hope I have answered all your questions, but if not, please ask here or in the ASRock forum.  Thanks and enjoy, John.

[cdob]

It's a rather curious behaviour.

One driver difference:

Asrock AMD RAID driver ver:9.00.00.088 rcbottom.inf uses WdfCoInstaller01011.dll.
Injecting this driver to boot.wim is difficult.
If I recall correctly, Windows 7 dism didn't set service load because of a WdfCoInstaller.
No Idea about 1709 dism.exe.

The AMD 9.1.0.18 rcbottom.inf does not use WdfCoInstaller.
Injecting this driver to boot.wim should be simpler.
https://www2.ati.com/drivers/raid-windows-driver-9_01_00_018.zip

[johnhc]

Wow, thanks cdob!  I need to spend some time understanding what you are saying!

If I recall correctly, Windows 7 dism didn't set service load because of a WdfCoInstaller.

Don't know what this means.  If you will tell me how to check on the latest DISM, I will check it out.  Your link gave "Download Not Complete", but just going here, bottom I found AMD RAID drivers 8.1.0.00018, 8.1.0.00026 and 8.1.0.00075.  I have shied away from the AMD drivers since ASRock has modified them and they give a yellow ! in Device Manager (ASRock now offering no update) but I may give AMD ones them a try.  Thanks much and enjoy, John.

[cdob]

Let's see.

md c:\mount
dism /Mount-Wim /WimFile:U:\sources\boot.wim /index:2 /MountDir=c:\mount
dism /image=c:\mount /add-driver:C:\driver\WTx64 /recurse
dism /UnMount-Wim /MountDir=c:\mount /commit

 

Quote

 

[HKEY_LOCAL_MACHINE\pe_system\DriverDatabase\DeviceIds\PCI\CC_010802]
"stornvme.inf"=hex:01,ff,00,00
"oem0.inf"=hex:01,ff,00,00

[HKEY_LOCAL_MACHINE\pe_system\DriverDatabase\DeviceIds\PCI\VEN_1022&DEV_7917&CC_0104]
"oem0.inf"=hex:01,ff,00,00

[HKEY_LOCAL_MACHINE\pe_system\DriverDatabase\DeviceIds\PCI\VEN_1022&DEV_43BD&CC_0104]
"oem0.inf"=hex:01,ff,00,00

[HKEY_LOCAL_MACHINE\pe_system\ControlSet001\Services\rcbottom]
"Start"=dword:00000000
"DisplayName"="@oem0.inf,%rcbottom.SVCDESC%;AMD-RAID Bottom Service"
"LoadOrderGroup" = "SCSI miniport"

[HKEY_LOCAL_MACHINE\pe_system\DriverDatabase\DeviceIds\SCSI\ProcessorAMD-RAIDConfiguration___V8.0]
"oem1.inf"=hex:01,ff,00,00

[HKEY_LOCAL_MACHINE\pe_system\DriverDatabase\DeviceIds\SCSI\ProcessorAMD-RAIDConfiguration___V9.0]
"oem1.inf"=hex:01,ff,00,00

[HKEY_LOCAL_MACHINE\pe_system\DriverDatabase\DeviceIds\SCSI\ProcessorAMD-RAIDMultiCard_______V8.0]
"oem1.inf"=hex:01,ff,00,00

[HKEY_LOCAL_MACHINE\pe_system\DriverDatabase\DeviceIds\SCSI\ProcessorAMD-RAIDMultiCard_______V9.0]
"oem1.inf"=hex:01,ff,00,00

[HKEY_LOCAL_MACHINE\pe_system\ControlSet001\Services\rccfg]
"Start"=dword:00000003
"DisplayName"="@oem1.inf,%rccfg_Desc%;AMD-RAID Config Device"

[HKEY_LOCAL_MACHINE\pe_system\DriverDatabase\DeviceIds\{54cb850d-a731-8590-0628-1992592bd448}\rcbottom]
"oem2.inf"=hex:01,ff,00,00

[HKEY_LOCAL_MACHINE\pe_system\ControlSet001\Services\rcraid]
"Start"=dword:00000000
"DependOnService" rcbottom
"Owners" oem2.inf

 

Do you use SATA RAID or NVMe RAID?
Wich HardwareID matches your mass storage controller?

rcbottom.sys is a storport.sys and wdfldr.sys child driver.
The "PCI\CC_010802" may conflict with stornvme.sys.
https://msdn.microsoft.com/en-us/library/windows/desktop/mt718131.aspx
Which driver get's the higher PNP priority, the in-box stornvme or the third party rcbottom?
In doubt I would delete DriverDatabase\DeviceIds\PCI\CC_010802\stornvme.inf.

The demand start Services\rccfg\Start=3 is curious too. 
I would try the default Start=3 first. And if it fails, Start=2, Start=1, Start=0 next.

X399 NVMe RAID seem sot be a new feature.
https://community.amd.com/community/gaming/blog/2017/10/02/now-available-free-nvme-raid-upgrade-for-amd-x399-chipset
http://support.amd.com/en-us/kb-articles/Pages/NVMe-RAID-Support-for-the-AMD-Ryzen-Threadripper-platform.aspx
http://forum.asrock.com/forum_posts.asp?TID=6453&PN=4&title=taichi-x399-cannot-install-windows-in-raid-mode
http://forum.asrock.com/forum_posts.asp?TID=6751&PN=2&title=x399hd-not-showing-in-uefi-boot-list-in-raid-mode

 

[johnhc]

cdob, I know how to inject drivers using DISM and have a large .CMD file to do all my work at once.  All of your links at the bottom point to the "available free" article.  The last two look familiar and I probably contributed to both.  I do not know enough to answer your questions and am wondering why you posted all the Registry keys.  I will not be modifying any drivers.  I have just begun to research all this and will continue.  Thanks and enjoy, John.

[cdob]

Yes, you contributed to both articles. And no doubt you can add drivers at dism,
I understand, you like to use 3x NVMe Samsung SSD 960 EVO at RAID mode.

The registry keys are a documentation, how does dism integrate the *.inf files?
Are there any clitches at first glance?
A possbile driver stack is included, but I doub't some details. However I've no hardware to test.
The suggestion was to run regedit.exe or reg.exe after dism run. And edit the file system32\config\system.
Integrating working drivers would be nice.

Did you finish installation with the 8 GB USB?  Do you use a running Windows 10 already?
Run device manager, change view per connection, search the raid disk, go some steps up to AMD-RAID Bottom
View details, select HardwareID.

Or boot a PE, run regedit.exe, search for data "PCI\CC_01". Goto HardwareID.

Or run devcon to list mass storage controllers

devcon.exe hwids *cc_01*

https://docs.microsoft.com/en-us/windows-hardware/drivers/devtest/devcon
https://networchestration.wordpress.com/2016/07/11/how-to-obtain-device-console-utility-devcon-exe-without-downloading-and-installing-the-entire-windows-driver-kit-100-working-method/

What about boot the 8 GB USB, read drivers from the 8 GB USB and apply windows files from the 16 GB USB?

Or install to a SATA WD disk. Build a NVMe RAID at UEFI. Install RAID drivers. Clone windows to the NVMe RAID.

Another approach: X399 NVMe RAID is a new feature, get some time to rest.
Wait half a year, try current BIOS, drivers, 960 firmware updates again.