Jump to content











Photo
- - - - -

Boot windows 10 vhd from usb (also ramboot)


  • Please log in to reply
14 replies to this topic

#1 favorinus

favorinus

    Newbie

  • Members
  • 24 posts
  •  
    Aland Islands

Posted 3 days ago

Hi,

 

I am trying to make a stripped down windows 10 vhd for booting from USB.

My goal is to have a small windows 10 running in RAM loaded from USB. I have done this with XP and windows 8, but now I am stuck with windows 10.

 

steps I made: 

 

removed the useless things from windows 10 with Winreducer. 

install the produced ISO with mode: LZX into VHD with WinNTsetup 4.2.1

 

run the vhd in virtuablx to check anything running smooth and install svbus 1.1 while in virtualbox running.

 

prepare usb stick for BIOS booting: format it one partition NTFS with grub4dos booting.

 

title W10Q1900.vhd  RAMDISK  - 2 GB
find --set-root --ignore-floppies /W10Q1900.vhd
map --mem /W10Q1900.vhd (hd0)
map --hook
root (hd0,0)
chainloader /bootmgr
 
title W10Q1900.vhd    FILEDISK  - 2 GB
find --set-root --ignore-floppies /W10Q1900.vhd
map /W10Q1900.vhd (hd0)
map --hook
root (hd0,0)
chainloader /bootmgr

 

the RAMdisk is booting fine, the pendrive is also mounted 

 

the FILEDISK gives me an inaccessible boot device BSOD

 

what can I do to correct this, seems like a mass storage driver problem ? How to check and correct.

 

thank you!


Edited by favorinus, 3 days ago.


#2 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15386 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 3 days ago

It's strange, SVbus has been developed exactly because previous drivers had sometimes those issues with Windows 10:

http://reboot.pro/to...b4dos/?p=207138

 

I cannot see anything that is not "as it should be" in the procedure you report for the creating of the image. :unsure:

 

The "inacessible boot device" (0x0000007b) BSOD is definitely connected to the mass storage drivers in use, but if there was some sort of incompatibility with SVBUS, it would have probably created the same issue also as Ramdisk. :dubbio:

 

Can you try (only for the sake of the experiment) to copy the W10Q1900.vhd to the internal hard disk (still booting from the pendrive, i.e. leaving the grub4dos on the USB stick, but removing - or renaming - the W10Q1900.vhd in the pendrive)?

 

Maybe the issue is in the USB drivers, this way they are outside the protected mode part of the booting.

 

:duff:

Wonko


  • antonino61 likes this

#3 favorinus

favorinus

    Newbie

  • Members
  • 24 posts
  •  
    Aland Islands

Posted 3 days ago

I have copied the vhd to a hdd and now it's booting fine with filedisk booting.

so the issue is with the usb mass storage drivers, they are install but not loaded early enough? 

 

what can I do now?



#4 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15386 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 3 days ago

I don't know.

 

Windows 10 should have "native" and "working everywhere" USB (3.0) drivers :unsure:

 

Could it be - for some reasons - that your "passing through" VirtualBox has changed some settings related to the USB bus?

 

Now that you are filedisk booted from the .vhd on hard disk can you check that everything related to USB is OK?

 

Or maybe it has been already "fixed" by booting on the "real hardware".

 

I.e. if you now switch off the PC, reboot to your normal OS and copy back the booted .vhd from disk to USB stick, is it still the same?

 

You can also try (but I don't think it will make any change) to use the grub4dos USB stack ( add "usb --init" as first line in your tiltle(s) in menu.lst).

 

:duff:
Wonko 



#5 alacran

alacran

    Gold Member

  • .script developer
  • 1436 posts
  •  
    Mexico

Posted 2 days ago

@ favorinus

 

This are examples for Wimboot VHDs as filedisk or Ramdisk having SvBus driver installed (only required for Ramboot), using grub4dos 0.46a last version:

 

Ramboot from internal disk:

title 10x64-WB.vhd - SVBus  RAMDISK  - map as (hd) for WIMBOOT
find --set-root --ignore-floppies /10x64-WB.vhd
map --top --mem /10x64-WB.vhd (hd)
map --hook
root (hd-1,0)
chainloader /bootmgr

Filedisk booting from internal disk:

title 10x64-WB.vhd - SVBus  FILEDISK - map as (hd) for WIMBOOT
find --set-root --ignore-floppies /10x64-WB.vhd
map /10x64-WB.vhd (hd)
map --hook
root (hd-1,0)
chainloader /bootmgr


Ramboot from external disk:

title 10x64-WB.vhd - SVBus  RAMDISK - map as (hd-1) for WIMBOOT

find --set-root --ignore-floppies /10x64-WB.vhd
map --top --mem /10x64-WB.vhd (hd-1)
map --hook
root (hd-1,0)
chainloader /bootmgr


Filedisk booting from external disk:

title 10x64-WB.vhd - SVBus  FILEDISK - map as (hd-1) for WIMBOOT
find --set-root --ignore-floppies /10x64-WB.vhd
map /10x64-WB.vhd (hd-1)
map --hook
root (hd-1,0)
chainloader /bootmgr

 

Booting Wimboot VHDs has extremely precise requirements to first find the info into the new virtual drive (the VHD during booting) and also let the pointers inside the VHD find the source.wim coupled to it, (located on the USB device).

 

About your issue:

 

FILEDISK gives me an inaccessible boot device BSOD

 

This is caused when during boot the internal info contained into the VHD or the associated Wim file is not found, and may happend during RAMboot and/or filedisk booting that's the reazon to use root (hd-1,0) line on previous examples, and then avoid this issue in all cases:

 

Use yor actual titles.

Adapt previous commands with your VHD name.

 

Where using:

root (hd-1,0), the USB device is hd0, and the virtual disk is or will be hd1

 

Actually you have root (hd-0,0) on all your commands.

 

If this don't solve your issue, it is also possible you have something wrong on the internal BCD of your VHD (I really don't think it is the case). But it is better to give you also following info:

In that case you could also use UEFI_MULTI or VHD_WIMBOOT from wimb, if using a NT 6.x  MBR on your USB, both make  entries on BCDs + an entry for grub4dos grld.mbr and add it and grld, and make also requiered entries to menu.lst for filedisk and Ram booting, and additionaly make an enty into the VHD internal BCDs.

 

EDIT: See attached photo (as a guide) of the generic BCD valid when the VHD is on the root of a drive, wich is good when filebooting or rambooting from internal and external mass storage devices.

 

alacran

Attached Thumbnails

  • BCD into the VHD.png


#6 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15386 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted A day ago

@alacran

Ramdisk booting already works just fine.

 

The filedisk booting from USB (but not from internal disk) is the issue at hand.

 

Now you explain to me which differences there are between:

 

 

Filedisk booting from external disk:

title 10x64-WB.vhd - SVBus FILEDISK - map as (hd-1) for WIMBOOT
find --set-root --ignore-floppies /10x64-WB.vhd
map /10x64-WB.vhd (hd-1)
map --hook
root (hd-1,0)
chainloader /bootmgr

 

and:

 

 

title W10Q1900.vhd FILEDISK - 2 GB
find --set-root --ignore-floppies /W10Q1900.vhd
map /W10Q1900.vhd (hd0)
map --hook
root (hd0,0)
chainloader /bootmgr

 

As I am completely missing them.

 

:duff:

Wonko



#7 alacran

alacran

    Gold Member

  • .script developer
  • 1436 posts
  •  
    Mexico

Posted A day ago

My suggested commands for Ramboot and for filedisk boot, have proven to be reliable on all scenarios to boot any VHD, including standard VHDs, Wimboot VHDs and Compact installed VHDs, and so far are same used into UEFI_MULTI and WIMBOOT_VHD programs by wimb for any kind of VHDs.

 

In fact they are based on karyonix info.

 

Then I could say with no dubt they are the only fullprove option valid for any kind of VHD.

 

Unfortunately the info is in several parts on some post located on this topic, where you and I were involved too:

 

http://reboot.pro/to...e-8#entry209770

 

Also this were my finding during my test:

 

http://reboot.pro/to...s-svbus-driver/

 

EDIT: also don't forget the final comment on my previous post:

 

If this don't solve your issue, it is also possible you have something wrong on the internal BCD of your VHD (I really don't think it is the case). But it is better to give you also following info....

 

 

alacran



#8 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15386 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted A day ago

I don't want to be grumpier than usual, but the OP issue is NOT about Ramdisk booting that works just fine. (so it makes no sense to post a solution about a non-issue).

 

The issue is about Filedisk booting (and Filedisk booting from USB ONLY).

 

You cannot (actually you can just fine :)) post a suggestion that is (seemingly) functionally IDENTICAL to what the OP is already using (and failing with) unless you explain in what it is different (and hopefully better).

 

The point (there and in a different context) was about assigning something to (hd) (next disk drive) and chainloading (hd-1) i.e. last drive before the next one:

In this post you are suggesting to assign something to (hd-1) and then chainloaing the same (hd-1), so it seems to me very, very like using in both lines (hd0).:dubbio:

 

:duff:

Wonko



#9 alacran

alacran

    Gold Member

  • .script developer
  • 1436 posts
  •  
    Mexico

Posted A day ago

 

In this post you are suggesting to assign something to (hd-1) and then chainloaing the same (hd-1), so it seems to me very, very like using in both lines (hd0).

 

Agree.

 

The idea was to let favorinus know this general use commands, without looking/analyzing very carefuly he should get similar results with hd0, on standard VHDs.

 

Then the only other possible cause of the issue should be on the BCD of the VHD.

 

I'm going to edit that post and add a picture of the generic BCD valid when the VHD is on the root of a drive, wich is good when filebooting or rambooting from internal and external mass storage devices.

 

Thanks for your comment into my quote, it was the key that made me look the similar results, on standard VHDs.

 

It is good someone let you know when you misslook something.

 

alacran



#10 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15386 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted A day ago

Then the only other possible cause of the issue should be on the BCD of the VHD.
 
I'm going to edit that post and add a picture of the generic BCD valid when the VHD is on the root of a drive, wich is good when filebooting or rambooting from internal and external mass storage devices.

I don't know. :dubbio:
 
The error is a 0x0000007b, which should happen post BCD and definitely is related to mass storage device (or its drivers).

If you prefer, the chainloading of BOOTMGR must be working (itherwise he would have a grubdos error), then the BCD must be found (otherwise he would have a "missing BCD" error 0xc0000034, "The Boot Configuration Data file is missing."), but it goes a bit further, either WINLOAD.EXE is also found (or he would have a 0xc000000f "The selected entry could not be loaded because the application is missing or corrupt.") or - and this is what I believe - the issue happens within BOOTMGR but post BCD the sheer moment the devices are re-enumerated due to the "switch" between real and protected mode, i.e. between BCD and WINLOAD.EXE.

 

Of course it doesn't happen on Ramdisk (as the whole stuff is already loaded in memory and mapped correctly by grub4dos) and - less obviously but still making sense - it doesn't happen if the VHD is on the internal disk (surely accessible).

 

So what remains is something connected to the BIOS (these days unlikely), to USB drivers (more likely) or to the particular stick used (rare but possible[1])

 

There was something "loosely" similar to this related to installing XP from USB:
https://msfn.org/boa...er-d-and-not-u/

 

:duff:

Wonko

 

[1] Anecdata, many years ago I removed the serial number from a USB stick while making an unrelated experiment with it, then several weeks later tried a particular software (sort of portable dektop/environmentm cannot really remember the name) and there was no way I could install/run it on that particular stick (but it worked just "fine" - actually it was essentially some crappy stuff - on *any* other stick I tested it on). Long story short, after I re-used the stick "Manufacturer Tool" to re-assign to the stick a serial, the program started working even on that stick.  



 



#11 alacran

alacran

    Gold Member

  • .script developer
  • 1436 posts
  •  
    Mexico

Posted A day ago

 

The error is a 0x0000007b, which should happen post BCD and definitely is related to mass storage device (or its drivers)...

 

So what remains is something connected to the BIOS (these days unlikely), to USB drivers (more likely) or to the particular stick used

 

What I would do then (free options first, starting with possible human errors):

 

It doesn't hurt to verify the BCD first, just to descart that something is wrong in it.

 

Check current Bios settings related to USB, just to descart that something is wrongly selected.

 

Try same USB on all MBR USB port available, usually they supply better Volts, Ampers and transfer speed than front ports.

 

Try booting on another PC with current USB device.

 

Check MB/PC manufacturer page to see if there is a new Bios version, and install it if available, even if there is no mention related to USB, (sometimes they don't mention all changes/improvements).

 

Try using another USB device (preferable new and a reputable brand), to discart incompatibility.

 

If nothing on this list solves the issue buy a new PC (just joking).

 

alacran



#12 favorinus

favorinus

    Newbie

  • Members
  • 24 posts
  •  
    Aland Islands

Posted A day ago

thank you all for the replies, but still no joy,

 

the internal bcd is the same as posted by alacran,

I will try another usb stick

 

the bsod also occurs on an another PC.


Edited by favorinus, A day ago.


#13 favorinus

favorinus

    Newbie

  • Members
  • 24 posts
  •  
    Aland Islands

Posted A day ago

As a work-around I tried to boot the  vhd as FILEDISK using windows 10 native vhd boot.
 
first boot to grub4dos
 
then
title Windows 10 native VHD
chainloader /bootmgr10
 
this loads  /boot/BCD
 
which will look for W10Q1900.vhd 

 

this results in a
 
VHD  BOOT INITIALIZATION FAILED

 

????



#14 alacran

alacran

    Gold Member

  • .script developer
  • 1436 posts
  •  
    Mexico

Posted 23 hours ago

After reading again your first post looking very carefuly if I missed some info, this are my findings.

 

From your fist post:

 

 

My goal is to have a small windows 10 running in RAM loaded from USB. I have done this with XP and windows 8, but now I am stuck with windows 10.

 

Does the 8 VHD boots fine as filedisk and ramdisk on your current USB device?

 

If the answer is NO, your USB maybe is not working fine or is not fully compatable with your PC under certain circunstances.

 

If the answer is YES, then the problen could be related to the following:

 

 

steps I made: 

 

removed the useless things from windows 10 with Winreducer.

install the produced ISO with mode: LZX into VHD with WinNTsetup 4.2.1

 

run the vhd in virtuablx to check anything running smooth and install svbus 1.1 while in virtualbox running.

 

If you installed the Virtual Box additional package it has its own drivers and other things to improve the VM funcionality, perhaps this overwrited the original USB drivers, part of them, or the services required to start the driver, the entries on the reg file controling the timings of this service, etc

 

About SvBus driver, on post No. 115 the author says:

 

 

SVBus V1.2 Virtual SCSI Host Adapter for GRUB4DOS

Today we present the new virtual SCSI driver SVBus version 1.2 for use with GRUB4DOS. SVBus V1.1 was not working correctly in combination with Windows 10 x64 Build 1803 and later. This could lead to a system crash with BSOD and the error CRITICAL_PROCESS_DIED. We discovered a Microsoft bug in esent.dll, which lead to these critical errors. Details are listed in the ReadMe.txt topic named "Application and Service Crashes on Windows 10 x64 Build 1909 with SVBus version 1.1".

In addition we added mode page caching for the MODE SENSE (6) command. The virtual HDD needs MODE PAGE CACHING to display the tab Policies in the Properties of the HDD in device manager.

 

To download the newest version use the link in my first post.

 

Much respect go out to all the heroes who work very hard in hospitals all over the world at the moment to fight COVID-19.

Keep up your amazing work and spirit!

 

Greets
Kai Schtrom

 

Better use SVBus version 1.2 on a new build, and better don't use any Virtual Machine, you don't need it, create the VHD on a partition of your PC, WinNTSetup will create the entry on your PC BCD to let you boot from it.

 

I noticed in your last post you followed more or less the instructions from SVBus author, they are not bad but in my next post (to not miss the target of this post), I will suggest you my manual  way, or the automated way using WIMBOOT_VHD by wimb.

 

For next comment I will consider the USB device is OK:

 

Abut the use of Winreducer: as the 10 OS on the VHD boots fine when loaded on RAM (by grub4dos) and only fails when starts file booting there is also the possibility the USB funtions are not working to its full capacity because some part of the driver, the services required to start the driver, the entries on the reg file controling the timings of this service, etc were affected during the reduction with Winreducer.

 

alacran



#15 alacran

alacran

    Gold Member

  • .script developer
  • 1436 posts
  •  
    Mexico

Posted 10 hours ago

I recommend you to start from scratch a new build.

 

The procedure made by SVBus author Kai Schtrom is not bad, but I have the opinion the procedures here on reboot.pro are better, as give the user more booting alternatives (MBR & UEFI), using Windows bootmanager + grub4dos and also grub (optional) to let the user include (boot) also Linux distros on same USB device, and do not modify/delete files related to Windows boot files/folders, not only using grub4dos alone as boot loader (good only for MBR).

 

My topics related to Wimboot and Compact Installs (manual procedures)

 

Read this first:

Following topic has info related to Compact Mode Installs: (basically same applies for Wimboot Installs too):http://reboot.pro/to...-mode-installs/

 

You can skip this, but it has all procedure in detail for Wimboot installs and has good info and test done:

Long topic about Wimboot Installs: http://reboot.pro/to...vhd/?hl=wimboot

 

 

Wimb programs to automate Wimboot and Compact Installs:

 

USB Format Tool and UEFI_MULTI: http://reboot.pro/fi...and-uefi-multi/

 

VHD_WIMBOOT - Apply and Capture of WIM Files for OS in VHD: http://reboot.pro/fi...-for-os-in-vhd/

NOTE: Good for Standard, Wimboot and Compact installs. Into this download is included a pdf file with recommended procedure.

 

Let us know latter if this helped you to solve the issue.

 

i wich you good luck in your builds

 

alacran






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users