Jump to content











Photo

Install Win10XPE_x64 Flat or Compact Mode on VHD

win10xpe_x64 flat install compact install vhd

  • Please log in to reply
115 replies to this topic

#51 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 01 October 2020 - 06:12 PM

Attached pictures of my 7pe_amd64_E_LZX.vhd, the WinPE was made long time ago, now I updated 7-zip and also added WinNTSetup 4.2.3 + some portables to Documents folder and shortcuts for them on the desktop.

 

The PC-Context Menu has a link to a *.cmd to install it (manually every boot), I tried to put the link on Startmenu\Start but it is not running when booting, I would like to find a way to make this automatic, maybe editing some *.ini

 

Any ideas?

 

alacran

 

 

Nice to see that 7pe is still alive  :thumbsup:

 

Have a look at how the other desktop icons are created Or Add WinNTSetup to PStart Menu

 

Boot 7pe > create link > copy Link to Make_PE3-48\PE3_mod\PE3_add\amd64\Users\Default\Desktop > boot to other OS > Run Make_PE3.exe to make 7pe

 

Easier is just Add WinNTSetup to PStart Menu

 

Alive and kicking after many years, my friend.

 

Thanks for your suggestion, but WinNTSetup and other Portables added to Documents (just for testing pourposes), already have new shortcuts created on desktop (directly on the running 7pe.vhd) working fine, so no problem with this.

 

And yes usually I use PStart to run programs from outside the VHDs or WinPEs, usually located on a USB partition/drive root, preferable NTFS formated to keep them LZX compressed (to save espace) and also make them available for all VHDs and WinPEs from a single location.

 

What I'm trying to accomplish (if possible) is find a way to run a *.cmd or an *.exe automatically every boot, (without rebuild the 7-WinPE), and don't have to run it manually every boot.

 

The command writes to Registry, and as Registry is volatile, it has to be run every boot.

 

Any ideas?

 

alacran



#52 wimb

wimb

    Platinum Member

  • Developer
  • 3756 posts
  • Interests:Boot and Install from USB
  •  
    Netherlands

Posted 01 October 2020 - 06:47 PM

Modify AutoIt3 code Make_PE3-48\PE3_mod\PE3_add\amd64\Windows\SysWOW64\PStart.au3 which is launched by startnet.cmd (also present in that folder)

 

You might add some AutoIt3 code that does what you require. Then make new 7pe

 

Boot 7pe and then your code is executed together with search for \PStart\PStart.exe


  • alacran likes this

#53 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 04 October 2020 - 03:58 AM

Thanks very much for your detalided and fast answer.

I didn't answer before because was still working to solve this subject.

I opened startnet.cmd and took a look of the code, yes in fact as you said, it runs:

"X:\Program Files\wall-cmd\Wallcmd.exe" /AutoIt3ExecuteScript "X:\Windows\SysWOW64\PStart.au3"

Then I took a look to the *.cmd I want to run when booting, and it is beyond my little skills with AutoIt3, only program I have made in AutoIt3 is lz4_compressor and it was with a lot of help and guidance from my good friend Retokener, and I haven't make more intents to learn more on AutoIt3.

 

By the way Make_PE3-48 download links are not working anymore.

 

But I had an alternative idea, and made PC-CTMenu.exe from the PC-CTMenu.cmd by means of Bat_To_Exe_Converter v3.2 portable, (x86 run hiden selected) and edited startnet.cmd adding this line: X:\Windows\SysWOW64\PC-CTMenu.exe

After your line: X:\Windows\Sysnative\regedt32.exe /S X:\Windows\SysWOW64\PE3_CUSTOM.reg

And copied PC-CTMenu.exe.exe to Windows\SysWOW64\PC-CTMenu.exe

 

All working now as I wanted. 

Again thanks very much for your answer, even if I wasn't able to follow your instructions, it helped me to find an alternative solution.

 

In fact I was totally forgotten about startnet.cmd to run a program when a WinPE boots. I Only hope it is not Alzheimer. :D

 

Win10XPE uses Pecmd.exe and Pecmd.ini launched from : RegWrite,HKLM,0x1,Tmp_System\Setup,CmdLine,"Pecmd.exe Main #$pWindir#$p\System32\Pecmd.ini"

 

And editing Pecmd.ini on _SUB PostShell section adding a line to run my new little PC-CTMenu.exe or PC-CTMenu_x64.exe, should run it automatically:

 

EXEC %WinDir%\SysWOW64\PC-CTMenu.exe

or maybe better:

EXEC %WinDir%\System32\PC-CTMenu_x64.exe

 

EDIT: Just in case some reader want to try PC-CTMenu, on his WinPE flat or Compact installed on VHD, see attachment:

 

alacran

Attached Files



#54 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 04 October 2020 - 10:17 AM

Why, wouldn't the plain .cmd run just fine from startnet.cmd ? :dubbio:

 

:duff:

Wonko



#55 wimb

wimb

    Platinum Member

  • Developer
  • 3756 posts
  • Interests:Boot and Install from USB
  •  
    Netherlands

Posted 04 October 2020 - 11:33 AM

Nice to hear that you have found a solution that works for you.

 

Unfortunately your PC-CTMenu.zip is considered as a Virus by Windows Defender.

 

Can you publish the PC-CTMenu.cmd that you are using ?

 

As Wonko proposes it might be easier to just modify startnet.cmd for your purpose.



#56 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 04 October 2020 - 05:15 PM

Sure, a full set of original commands (3.47 KB) was attached to this post: http://reboot.pro/to...e-2#entry215558

 

I renamed AutoTranslated-PC-CTMenu-names.cmd to PC-CTMenu.cmd, and as there is no way it recognizes it is running as admin on 7pe_amd64_E_LZX.vhd, I deleted all lines related to this, and commented lines related to Task Scheduler too, as Task Scheduler is not running on a PE environment.

 

Then it worked fine when ran, it was copied to wall-cmd folder, and tried to launch it from startnet.cmd, adding this line:

 

"X:\Program Files\wall-cmd\PC-CTMenu.cmd"

 

But it didn't work, and that's why I made the *.exe

 

alacran


  • wimb likes this

#57 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 04 October 2020 - 06:35 PM

Are you using the call command?

Or maybe you need to spawn a new instance of cmd?

 

:duff:

Wonko



#58 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 04 October 2020 - 07:08 PM

I only added the line:

 

"X:\Program Files\wall-cmd\PC-CTMenu.cmd"

 

No more, maybe it was necessary to run first %windir%\system32\cmd.exe /S

 

Using something like this:

 

%windir%\system32\cmd.exe /S  "X:\Program Files\wall-cmd\PC-CTMenu.cmd" /S

 

Or perhaps you can improve it.

 

alacran



#59 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 04 October 2020 - 10:43 PM

Nice to hear that you have found a solution that works for you.

 

Unfortunately your PC-CTMenu.zip is considered as a Virus by Windows Defender.

 

Can you publish the PC-CTMenu.cmd that you are using ?

 

As Wonko proposes it might be easier to just modify startnet.cmd for your purpose.

 

I'm quite sure my PC is clean, I use Avast Free and at least twice a month run AddAware antimalware free.

 

Only programs allowed on Firewall App Blocker v1.7 white list, to internet trafic are FireFox and Avast to install virus definitions, evertyhing else is blocked, since last time the 7 & 10 OSs were installed.

 

Allowed:

C:\Program Files\Mozilla Firefox\firefox.exe

C:\Program Files\Avast Software\Avast\setup\instup.exe

 

I verified both with Avast AV and they are clean, on Virus Total several stupid AV claim to found something (but all of them a different thing).

 

The *.cmd used to create the *.exe(s) writes to the registy and maybe that's why some stupid AV consider it suspicious or malicious

 

Just to be sure I checked Bat_To_Exe_Converter_(x64).exe, and it is clean, See:  https://www.virustot...42cc6/detection

 

So I will continue using the two *.exe(s) I made, since so far I can't run the *.cmd from startnet.com

 

alacran



#60 wimb

wimb

    Platinum Member

  • Developer
  • 3756 posts
  • Interests:Boot and Install from USB
  •  
    Netherlands

Posted 05 October 2020 - 07:05 AM

It might be that it is just that Windows Defender does not like 32-bits apps and uses Block at First Sight.

 

Similarly my AutoIt3 32-bits apps are considered as a virus by Windows Defender.

 

I just mentioned the download problem, but I think there is nothing wrong on your side  ;)



#61 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 05 October 2020 - 08:13 AM

So I will continue using the two *.exe(s) I made, since so far I can't run the *.cmd from startnet.com

 

It's your system, of course :), but it still makes no sense that a batch doesn't start on it from startnet.cmd.

 

Besides the specific case you IMHO could (should) troubleshoot the issue. 

 

It is possible that *something* blocks it because it writes to the Registry, but I doubt it.

 

As a side note, that bat converter is (essentlally) a sfx (self extracting archive) wrapper, not entirely unlike a 7-zip sfx, so it is not that much improbable thatn this or that antivirus or similar see it as a menace.  

 

Try with:

 

call "X:\Program Files\wall-cmd\PC-CTMenu.cmd"

 

Possibly using a simpler batch *like*:

@ECHO OFF
CLS
ECHO Hi, I am running ...
PAUSE

Then try with:

start /wait "Title" "X:\Program Files\wall-cmd\PC-CTMenu.cmd"

and/or:

start /wait "Title" CMD.EXE /c "X:\Program Files\wall-cmd\PC-CTMenu.cmd"

 

https://ss64.com/nt/start.html

 

:duff:

Wonko



#62 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 05 October 2020 - 06:09 PM

I continue testing this because IMHO it could be useful on similar cases.

 

This is a summary of startnet.com:

 

"X:\Program Files\wall-cmd\Wallcmd.exe" /AutoIt3ExecuteScript "X:\Windows\SysWOW64\PStart.au3"

X:\Windows\Sysnative\regedt32.exe /S X:\Windows\SysWOW64\PE3_CUSTOM.reg

 

(Having the PC-CTMenu.cmd and PC-CTMenu.exe on Windows\SysWOW64 folder where startnet.com resides)

 

After the last line I have tested the following lines one by one just removing respective :: before booting, (keeping the others deactivated)

:: X:\Windows\SysWOW64\PC-CTMenu.exe  >>>  Proved to work fine

:: X:\Windows\SysWOW64\PC-CTMenu.cmd  >>>  Do not work

:: call X:\Windows\SysWOW64\PC-CTMenu.cmd  >>>  Do not work 

:: start /wait "Title" X:\Windows\SysWOW64\PC-CTMenu.cmd  >>>  The command is loaded, I can see its window (before reack desktop), but seems it do not run fine.

:: start /wait "Title" CMD.EXE /c X:\Windows\SysWOW64\PC-CTMenu.cmd  >>>  The command is loaded, I can see its window (before reack desktop), but seems it do not run fine.

 

If using the first line, once on desktop we can confirm PC (icon) right click shows fine Administrative Tools.

 

If using any other of the lines, once on desktop we can confirm in fact on PC (icon) right click do not shows Administrative Tools.

 

At the end of the command there are following lines to verify it ran fine.

 

echo Done.

:finished
timeout /T 5 >nul
exit

 

It looks to me there is a timming problem and the command is loaded (but seems not executed) on the wrong moment, it should run just after Windows reach desktop or at least after ran PS.exe, and we see the PStart menu, as it is done when using X:\Windows\SysWOW64\PC-CTMenu.exe, I think as it's seen as a Windows *.exe, it is executed when the OS is in contol.

 

And in fact when a *.cmd, it is loaded before, see attached picture, we should see Done. when ran fine.

 

alacran

Attached Files



#63 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 14 October 2020 - 06:00 PM

JFYI

 

I had a crazy idea:

 

Make a Wimboot VHD coupled to a WinPE.wim

 

For this experiment I made a new build of Win10XPE_x64 by ChrisR using the project's new version, used mainly the preselected programs with only one or two changes, all of them selected to run on Ram, and included also into the build a lot of portable programs (144 MB) contained on the root of the boot.wim, on Aplicaciones folder, and just copied the desktop shortcuts from my previous tests of Flat and Compact installations to Win10XPE\Custom\x64\AdditionalFiles\Users\Default\Desktop, also activated the Ramdisk (B:), to load there FireFox Profile Files, but deselected make the ISO, to let me edit certain things on target folders/files, once done I created the ISO, it is 844 MB, and the boot.wim is 818 MB.

 

Then I applied Wimboot attribute to the WIM file (with wimlib_Property_Switch by Retokener) and it was ready to install on Wimboot mode (used wimlib-clc by Retokener) on a 512 MB VHD, once installed it used about 40 + MB, I made the new entry on BCD (using BootIce) and it was ready for first boot, it loaded fine and I saw the desktop background image, but when it finished making the settings of drivers, registry editions, creation of RamDisk, sorthcuts, etc, there were some problems and a message appeared saying Real SystemRoot is C:\Windows, but it is set to X:\Windows use Dism /Set-TargetPath to fix this, and after acepting with the Intro (no mouse available) it lost the image and nothing was working, Then a black screen with PC, Recicle Bin and Star Icons, appeared, I had the mouse pointer available again, but all I wanted to do, did nothing, I had to use the Reboot button.

 

I went to read about the info got from the message, and I found this page: DISM Windows PE Servicing Command-Line Options, all there is very clear and well explained, then I mounted the WIM and tried to use the commands, they weren't able to moddify the WIM, even tried as Trusted Installer and same thing.

 

But I remembered some days ago I was able to read, see and compare the registry SYSTEM hives side by side using offlinereg by erwan.l, see: http://reboot.pro/to...e-5#entry216627

 

Offlinereg do not care about files permisions so it is the best option to edit protected sections of the Registry.

 

And I saw on:

 

HKEY_LOCAL_MACHINE\System\DriverDatabase

SetupStatus 259 REG_DWORD >>> on PE and >>> SetupStatus 0 REG_DWORD on regular windows

SystemRoot X:\Windows REG_SZ >>> on PE and >>> SystemRoot do not exists on regular windows

 

Then just edited that value to: C:\Windows and saved the SYSTEM hive.

 

But it was not all, as the Pecmd.ini used in Win10XPE_x64, has some references to X:\xxxxx, then I also edited them to C:\xxxxxx and rebooted again, then no more problems all booted fine, I noticed the 512 MB was too big for the used space and decided to edit on the Win10XPE\Target project the SYSTEM hive and the Pecmd.ini to my needs.  Once done and after set the Wimboot attribute, I made a new 300 MB VHD and made a Wimboot mode install with wimlib-clc, as I used same VHD name it was not necessary to edit the BCD again and it booted flawlessly. See attached picture.

 

After booting used size is 93.5 MB.

 

No matter the changes done (in the registry and the Pecmd.ini) the PE finally got drive letter X., all the editions were done to let it interact during first booting stages (it was in fact C: at that time).

 

Latter there is ran an instruction to switch drive letters, (haven't found the source yet), but when we finally are able to look it is already X:

 

Also there is a little progran LetterSwap.exe, It looks for a tag file on the root of all drives and if found that drive latter is switched to Y:, I really don't know exactly what else LetterSwap.exe does, on his log I can see:

 

Command Line: LetterSwap.exe/auto /SetLetter Y:\CDUsb.y /Log X:\Windows\TEMP\LetterSwap.log

 

Spoiler

 

This is a summary:

  • Make a PE build but don't create the WIM file and the ISO.
  • Edit on: HKEY_LOCAL_MACHINE\System\DriverDatabase  "SystemRoot"="C:\\Windows"
  • Edit on Pecmd.ini all instances of X: to C:
  • Comment on Pecmd.ini all under [PinUtil] section to avoid creating new shortcuts every boot.
  • Create the WIM file and the ISO.
  • Add Wimboot attribute to WIM file. (it already contains WimBootCompress.ini).
  • Install on Wimboot mode to a VHD.
  • Create BCD entries.
  • Boot.

alacran

Attached Files


  • wimb likes this

#64 wimb

wimb

    Platinum Member

  • Developer
  • 3756 posts
  • Interests:Boot and Install from USB
  •  
    Netherlands

Posted 14 October 2020 - 06:42 PM

I had a crazy idea:

 

Make a Wimboot VHD coupled to a WinPE.wim

 

 

Very Interesting Experiment  :)



#65 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 14 October 2020 - 07:06 PM

only for maintenance purposes?



#66 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 14 October 2020 - 07:30 PM

Only for learning, testing and the challenge purposes.

 

EDIT: A 150 MB VHD should be enough size, NOT lz4 compressed yet. Once lz4 Compressed it should load in microseconds, and if we omit creating the RamDisk B:, the used RAM should be ridiculous.

 

EDIT-2: Haven't solved the Ramboot part yet.

 

alacran


  • antonino61 likes this

#67 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 15 October 2020 - 02:44 PM

As you may imaginate, I couldn't resist the temptation to Make a Wimboot 150 MB VHD coupled to a WinPE.wim

 

I deleted some of the portables into Aplications (Aplicaciones) folder, FireFox is not included and also RamDisk (B:) was disabled and made a new Win10XPE_x64 Build.

 

Portables I kept:

  • Microsoft Calculator Plus v1.0
  • Notepad++
  • SwiftSearch
  • Wimlib-clc
  • WinContig
  • WOF_Compress

All with their respective shortcuts on desktop, and also with the exception of the first, the last and SwiftSearch, all the others also have a link on SendTo, and when a file is sended, they start running, with the file loaded, ready to work with it.

 

Win10XPE_x64.wim = 681 MB; Wimboot VHD = 150 MB;  used size is 48.7 MB; but after first boot used size is 98.2 MB, pictures attached.

 

By the way when I made the previous PE build and edited the Registry using Offlinereg_Gui, I was running 7, and all was fine.

 

This time I made same things but running 10 2004 and when saving the changes to SYSTEM hive I got a message saying changes were not made, tried a second time and same thing, then just closed the hive and the program and to my surprice the hive just dessapeared.

 

It's easier to edit the 10 Registry on 7 as it seems the 7 OS do not care very much about some new extended attributes implemented on 10, which is good in some cases.

 

I have noticed this when running 7 and applying 10 by means on wimlib-clc, see the attached picture after apply the image to the 150 MB, but nevertheless the VHD booted very fine. Also it is possible to run base_winsxs.cmd by cdob on a 7 PE without TI rights and is possible to reduce the WinSxS folder of a 10 OS, as gbrao mentioned in a post, and latter I confirmed, and also I have done this from a running 7 OS.

 

NOTE: Best way to edit the Registry (of a mounted VHD, or WIM or an offline OS on another drive) from any OS is using the command line offlinereg-win64.exe, just openinng a command as admin on same folder it is located, and running following line, (in this case I have a 10 VHD mounted on drive I:) adjust the path as required:

 

offlinereg-win64 "I:\Windows\System32\config\SYSTEM" " " import DriverDatabase.reg

 

Copy and save as: DriverDatabase.reg, and put it on same folder of offlinereg.

Spoiler

 

NOTE-2: I have tested running it on 7, 8.x and 10, and it works very fine.

 

The command line version of offlinereg do not care about the OS permissions and restrictions.

 

alacran

Attached Files



#68 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 08 November 2020 - 10:56 PM

JFYI

 

Following info from http://reboot.pro/to...t/#entry216445 also applies to a VHD Flat, Compact mode or Wimboot mode installed on a VHD:

 

 

  • Additional files required to keep to run LibreOfficePortable (multilang) are on Post No. 340.
  • Interesting info when using NTFS Compression + Compact LZX compression on Post No. 341.
  • Additional info about LibreOfficePortable on this Post
  • Additional useful links for your Mini-10x64-2004.vhd on this Post and this Post.

 

The only difference is the program LetterSwap.exe is already included on the Win10XPE on \Windows\System32 and it is executed automatically every boot, but the file named CDUsb.y, has to be on the root of the drive where you have your Programs, it is the tag file used to detect the drive that will be assigned as Y:

 

LetterSwap.exe is called by \Windows\System32\Pecmd.exe by means of a line on pecmd.ini on every boot.

 

alacran



#69 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 09 November 2020 - 09:05 PM

Listen to me, send both sysvolinfo and recycler to ram. no don't. just tried and it was not a good idea. resetting it back. Jesus Christ I got scared!!! all reference got lost. but thanx to run as admin, I managed to erase all sysvolinfos from all drives and all the recreations amount to zero now, on all drives, so from possible catastrophe to further reduction. rightly is they call it powerrun,  it is so powerful!!!



#70 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 10 November 2020 - 12:13 PM

Listen to me, <noise>

 

:duff:
Wonko


  • antonino61 likes this

#71 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 10 November 2020 - 01:14 PM

btw, with the same commands as the sysvolinfo ones I managed to reduce the recycle bin to a zero-byte file on each drive. unlike the sysvolinfo (which gets recreated), this one stays as a file and no folder gets recreated.



#72 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 04 July 2021 - 08:00 AM

Only for learning, testing and the challenge purposes.

 

EDIT: A 150 MB VHD should be enough size, NOT lz4 compressed yet. Once lz4 Compressed it should load in microseconds, and if we omit creating the RamDisk B:, the used RAM should be ridiculous.

 

EDIT-2: Haven't solved the Ramboot part yet.

 

alacran

 

The experiment Rambooting a Wimboot mode installed Win10XPE_x64 on a VHD after compressing the VHD file with lz4_compressor was pending since October-2020, sorry I forgot about this.

 

My recent new Win10XPE_x64-T.iso is 790 MB, the boot.wim file is 764 MB, It has several more programs into it including TeamViewer Portable v15 (that's the reason for the T, to differentiate it), then for this I used a 260 MB NTFS VHD to install it on Wimboot mode (used size is 94.1 MB).

 

The Ramboot part is solved now:

 

From this Post:

Spoiler

 

More details here:

Spoiler

 

The 10XPE_x64-T-WB.vhd after lz4 compressed is only 35.3 MB and it is loaded to ram instantaneouly, I can't measure the time it takes.

 

Now I think this topic finally has all the info.

 

alacran



#73 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 04 July 2021 - 09:17 AM

My recent new Win10XPE_x64-T.iso is 790 MB, the boot.wim file is 764 MB, It has several more programs into it including TeamViewer Portable v15 (that's the reason for the T, to differentiate it), 

 

You mean from the Win10XPE_x64-T.iso that has Tetris into it? :dubbio:

 

:buehehe:

 

Now, seriously, very good work!  :thumbsup:

 

:duff:

Wonko



#74 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 04 July 2021 - 11:16 AM

You mean from the Win10XPE_x64-T.iso that has Tetris into it? :dubbio:

 

:buehehe:

 

Now, seriously, very good work!  :thumbsup:

 

:duff:

Wonko

Good joke !!!, You made me laugh.

 

In fact that T is only temporary, I will delete it and edit all MBR/UEFI config/menu.lst files latter, it is there because I still have the previous version without "Tetris", and during tests in case of some boot issues on "Tetris" version, I boot to it to make some fast changes on the "Tetris" VHD or WIM files, as edit pecmd.ini, the Registry, etc., it boots faster than full OSs and also almost without any limitations booting as TrustedInstaller.

 

By the way, I have a question in my mind and I haven't find the answer by myself, maybe you can give some enlightenment.

 

It is a fact that if we Ramboot from a VHD it is possible to attach same VHD to service it as I have tested.

 

Why there is no collision if it is same drive with same ID or whatever windows calls it?

 

Could the answer be: when SVBus driver makes its magic, also makes the VHD loaded on Ram look different?

 

alacran



#75 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 04 July 2021 - 01:15 PM

It is a fact that if we Ramboot from a VHD it is possible to attach same VHD to service it as I have tested.

 

Why there is no collision if it is same drive with same ID or whatever windows calls it?

 

Could the answer be: when SVBus driver makes its magic, also makes the VHD loaded on Ram look different?

 

I believe it may (but it may not) be something slightly different.

 

A ramboot may (or may not) actually boot a volume "only".

 

Windows differentiation is (or at lest was) based on disks (not volumes) ID's.

 

Likely in your case of ramboot (cannot say if specific to the SVBus or not) the disk on which the boot volume resides (which is the VHD) is *somehow* not considered a "real" disk.

 

What do you see in Disk Manager when booted (in ramboot) to the .vhd AND have the same .vhd mounted?

 

Did you actually check that the Disk Signature of the .vhd remains the same (and it is not silently updated by the Windows)?

 

:duff:

Wonko







Also tagged with one or more of these keywords: win10xpe_x64, flat install, compact install, vhd

6 user(s) are reading this topic

0 members, 6 guests, 0 anonymous users