That @NTAuthority guy is not saying if its really booting or running in a VM / the Emulator ? Im eager to test it on some tablets and laptops, with and without touchscreens.
hm... first I wanted to say that I am not impressed if he got it working natively. But currently I don't have an Idea how to make it work natively. I don't know how to "wire" THIS VHDX (with multiple disks inside) into the BCD Store. I know how to implement and working with VHDX with 1 Disk but not with like 9 Disks inside 1 file. The BCD structure got many new items in the native image. Code: Windows-Start-Manager --------------------- Bezeichner {bootmgr} device partition=\Device\HarddiskVolume69 windowssyspart partition=\Device\HarddiskVolume75 path \efi\boot\bootx64.efi description Windows Boot Manager locale en-US inherit {globalsettings} testsigning Yes default {default} bootsequence {01de5a27-8705-40db-bad6-96fa5187d4a6} timeout 0 displaybootmenu No persistbootsequence Yes Windows-Startladeprogramm ------------------------- Bezeichner {311b88b5-9b30-491d-bad9-167ca3e2d417} device ramdisk=[\Device\HarddiskVolume71]\PROGRAMS\UpdateOS\UpdateOS.wim,{ramdiskoptions} path \windows\system32\boot\winload.efi description Windows Update OS (Boot from WIM) inherit {bootloadersettings} osdevice ramdisk=[\Device\HarddiskVolume71]\PROGRAMS\UpdateOS\UpdateOS.wim,{ramdiskoptions} systemroot \windows pae ForceEnable numproc 1 bootmenupolicy Standard detecthal Yes winpe Yes Windows-Startladeprogramm ------------------------- Bezeichner {default} device partition=\Device\HarddiskVolume71 path \windows\system32\boot\winload.efi description MAINOS locale en-US inherit {bootloadersettings} testsigning Yes allowedinmemorysettings 0x15000075 osdevice partition=\Device\HarddiskVolume71 osdatadevice partition=\Device\HarddiskVolume73 bspdevice partition=\Device\HarddiskVolume70 systemroot \windows bootmenupolicy Standard detecthal Yes debug Yes Windows-Startanwendung (1020000a) --------------------------------- Bezeichner {01de5a27-8705-40db-bad6-96fa5187d4a6} device partition=\Device\HarddiskVolume75 path \EFI\Microsoft\boot\mobilestartup.efi description Mobile Startup App inherit {bootloadersettings} recoverysequence {311b88b5-9b30-491d-bad9-167ca3e2d417} recoveryenabled Yes enablebootorderclean Yes enableiuloader Yes EMS-Einstellungen ----------------- Bezeichner {emssettings} bootems No Debuggereinstellungen --------------------- Bezeichner {dbgsettings} description Windows Debugger Settings key 20q0eg616u100.1d5bm61bpd3q2.xhibqi5mg60h.2xuml91g8nylg debugtype NET hostip 10.137.106.31 port 50001 dhcp Yes Globale Einstellungen --------------------- Bezeichner {globalsettings} inherit {dbgsettings} {emssettings} testsigning Yes extendedinput Yes nokeyboard Yes bootflow 0x0 Startladeprogramm-Einstellungen ------------------------------- Bezeichner {bootloadersettings} inherit {globalsettings} {hypervisorsettings} Hypervisoreinstellungen ----------------------- Bezeichner {hypervisorsettings} hypervisordebugtype Serial Optionen zum RAM-Datenträgersetup --------------------------------- Bezeichner {ramdiskoptions} description Ramdisk Options ramdisksdidevice partition=\Device\HarddiskVolume75 ramdisksdipath \boot\boot.sdi
Is it possible to mount it on build 17763? Explorer just shows the generic unable to mount error, and nothing appears in Storage Spaces. EDIT: Managed to mount it in a VM running build 18363.
I have no UEFI just now, but You may try this metod: "It is assumed that the reader is aware of how UEFI works (well, at least a little bit) What is required: 1. We need a computer with UEFI, a disk in GPT on it a partition in NTFS. (I used the systemd-boot bootloader). 2. BMGR files. 3. File win10.vhdx (The installation process in VHDX Win8 + x64 does not make sense to describe). How it works: 1. Copy the EFI / Microsoft directory to the EFI directory. 2. The file win10.vhdx is copied to the root of the NTFS partition (any). 3. If you use systemd-boot, manipulation of the bootloader is not required (if another, man will help you) 4. Windows installation is complete. Instructions for creating a BCD: Copy the BCD bootloader files to drive E. C: \ Windows \ System32> bcdboot.exe C: \ Windows / s E: / f uefi Duplicate the master record {default} C: \ Windows \ System32> bcdedit / store E: \ EFI \ Microsoft \ Boot \ BCD / copy {default} / d "VHD" We get {6cb5d1e6-4c58-11e8-bef8-d46e0e05804f} and set our record as the default entry. C: \ Windows \ System32> bcdedit / store E: \ EFI \ Microsoft \ Boot \ BCD / default {6cb5d1e6-4c58-11e8-bef8-d46e0e05804f} Now we indicate where the file is located (moreover, note the paths to partitions and disks are relative, and it is not even necessary that the file is in the root) C: \ Windows \ System32> bcdedit / store E: \ EFI \ Microsoft \ Boot \ BCD / set {default} device vhd = [locate] \ win10.vhdx C: \ Windows \ System32> bcdedit / store E: \ EFI \ Microsoft \ Boot \ BCD / set {default} osdevice vhd = [locate] \ win10.vhdx"
OK so I poked around in the filesystems that could be mounted (except for the first one and VailContainer since for some reason no options were available for them) for around an hour and noticed some interesting things. I also created WIM images of each partition I could access so I could browse through them easier without any permission issues blocking me. Please correct me if I'm wrong on certain things I listed. 1) winload.exe is actually present, but its location is different: MainOSDisk:\Windows\System32\Boot. 2) PreInstalledDisk is where all of the default UWP apps are stored. Not sure if they are copied to the DataDisk or are also installed user-side. 3) OSDataDisk contains general data created by the OS, like event logs and service profiles. Strangely, it also contains some of the registry hives, presumably so they can be modified by the system easily (the rest of the registry hives are stored on MainOSDisk). 4) DataDisk is probably where all of the user data lives. Has WindowsApps there as well, but the folders are all empty meaning most likely they are shortcuts pointing to the files stored on PreInstalledDisk. 5) No signs of standard Win32 programs like explorer, command prompt, registry editor, notepad, etc. This means if you break out of the restrictions somehow, you can't do much in the way of tinkering with the system. 6) UPDATEOS.wim located in MainOSDisk looks to be an incredibly slimmed down version of WinPE, but it's edition ID is OneCoreUpdateOS. Seems to be completely new, and contains a select few standard Win32 programs like command prompt. 7) In DataDisk:\ProgramData\Microsoft\Windows\Containers\BaseImages\a099a226-f2d7-4dc8-8880-a8e5f43e59e9\BaseLayer\ are two VHDX files, called SystemTemplate.vhdx and SystemTemplateBase.vhdx. SystemTemplate can't be mounted at all, while SystemTemplateBase can be mounted and explored after you give it a drive letter. SystemTemplateBase only contains a skeleton of system files though (all files inaccessible and have a gray X over them). 8) VailContainer seems to be a mystery. It can't be mounted at all, but actually uses up some space in the storage pool. Perhaps this is the partition or space that Win32 programs will have access to? Obviously there are more things hidden within the files that I missed or can't access, but someone more skilled than me can probably find them. Either way, it looks like Microsoft is locking down Windows 10X pretty hard and are taking lots of steps to stop users from tinkering with the system, similar to iOS. EDIT: Turns out you can sideload Command Prompt and other utilities through the Device Portal, which is a good sign (thanks to rcstar6696 for informing me). The standard Win32 programs are also present in ContainerOS located at MainOSDisk:\Windows\Containers\ContainerOS\GuestOnly\.
Well that's a good thing. Do they still run in an isolated environment? Or do they have full system access? I can't really run the emulator due to me disabling UWP apps on my PC, and because I have an AMD processor. EDIT: Do you mean the explorer.exe found in the containers present at MainOSDisk:\Windows\Containers\?
Me too. I'm wondering if we're going about this the wrong way. Maybe we should try creating an image from within the emulator rather than trying to convert the VHDX?
Could someone who was able to run directly on a machine without an emulator share the hard drive image with us?