wimb

How to Inject Win10 VHD System to Fix Computer In case of computer troubles it is often desired to have a quick fix available without disturbing existing configuration. We can decide to Inject from USB in 10 minutes a 50 GB VHD with New Windows 10 x64 System for local account. Windows 10 in VHD has the advantage that the VHD can be copied to any location. Windows 10 is Universal and will adjust automatically the drivers needed for the hardware in use. After Injection, the VHD System is personalised by Switching to Microsoft Account and Changing User Data Locations. - Prepare Portable SSD Bootable from USB with PE WIM and VHD file as described in this document Manual: Win10_Install.pdf - Disconnect Internet LAN Ethernet cable - Boot from USB - after beep use F8 menu - Select in Boot Manager Menu Win10XPE WIM file located on Portable SSD - Copy 50 GB VHD with New System for local account and located on USB Portable SSD to your internal SSD Drive C: - UEFI_MULTI is used to Add VHD in Boot Manager Menu for booting from internal SSD - BOOTICE use tab BCD and Z:\efi\microsoft\boot\BCD Or Z:\Boot\BCD in Prof Mode to Set as Default the Added VHD - Option - For existing System Drive C: use Malware Removal Tool like McAfee Stinger - Option - Restore Registry use Registry Backup Portable - Copy folders from RegBackup\MY-PC\datetime\C to Drive C: - Reboot from internal SSD by selecting in Boot Manager menu the Injected VHD with New Windows 10 x64 System - On Data partition Create 5x empty folder for Documents, Pictures, Downloads, Music and Videos My Computer - R-mouse on icon > Properties > tab Location > Move ... Select folder to change the User Data location - Swith to your Microsoft Account via Config > Accounts and Reboot - Option - Restore Backup of User Data made with SyncBack Free on external USB and kept safely offline - Connect Internet LAN Ethernet cable Alternatively you can use: How to Fix Booting of Windows 10 using bcdboot Use bcdboot to Fix on the hidden FAT32 drive the EFI\Microsoft\Boot\BCD entry Or Boot\BCD entry - Boot from USB - after beep use F8 menu - In Win10XPE use R-mouse menu to Open Admin Command Window - Use bcdboot to make BCD in your hidden FAT32 drive mounted by WinNTSetup x64 as Drive Z: bcdboot C:\Windows /s Z: /f ALL How to ReInstall Windows 10 If you want to ReInstall Windows 10 x64 while completely disturbing existing configuration then - Boot with Win10XPE from USB - after beep use F8 menu - In Win10XPE then - Backup to external USB drive your User Data from C:\Users\YourName - In WinNTSetup x64 use as Windows Installation file your Capture Wim file Or use Win10x64 ISO file from TechBench - Select as Installation drive your Attached VHD mounted as Drive Y: Or your internal SSD drive C: and Use NTFS Format - Select Setup and Legacy Boot Menu Style and OK to Install Win10x64 in VHD or partition of internal SSD and Reboot How to Backup your Computer A. System Backup - Swith off Defender - WinNTSetup - R-mouse menu - Local Windows Inst. - Capture Wim to make Backup WIM file - Time = 5 min The Captured WIM file of your System can be used for fast Re-Install of Win10 including all Programs and Settings - Registry Backup Portable can make a Backup in folder C:\RegBackup of the Windows Registry useful for System Restore - Time = 5 sec - MBR Backup can make Backup of Partition Table and Bootsectors of all Local Harddisks Fixed + Removable - Time = 10 sec Use TinyHexer to study and Restore Bootsectors - Hopefully Never Needed B. Data Backup - SyncBack Free - Make Backup of User Data on external USB kept safely Offline - Backup Time = initially few hours - update in 10 min - Backup using File History - available in Windows 10 - More Info - Time = initially few hours - autoupdate running in the background - Backup your Data in OneDrive in the Cloud - Backup kept safely on Remote Location - Time = initially few hours - autoupdate

How to Boot from USB with WIM or VHD file located on Portable SSD Make USB - Partition Portable SSD 500 GB - SAMSUNG Portable SSD T5 500 GB with UEFI/MBR Partitioning - 1st partition 20 GB FAT32 Set Active used for Boot Manager and Grub4dos Boot files - 2nd partition NTFS used for VHD + WIM System files 1. In Disk Management remove existing exFat Volume and Create new partitions 2. MBR partitioning with 1st partition 20 GB FAT32 Set Active used as Boot Drive and 2nd partition NTFS System Drive - Instead of step 3 and 4 using UEFI_MULTI will Set Active the USB FAT32 Boot Drive 3. In admin command window run DiskPart 4. In DiskPart type list volume and select volume <FAT32 volume nr> and active and exit BIOS mode booting requires Active partition with BOOTMGR bootsector UEFI mode booting requires FAT32 partition with x64 file efi\boot\bootx64.efi Or x86 file efi\boot\bootia32.efi Downloads: UEFI_MULTI and WinNTSetup and Windows 10 x64 ISO from TechBench Or using Windows-ISO-Downloader Tool More Info: UEFI_MULTI topic and Win10_Inst in Forums MSFN and Reboot.pro and VHD_WIMBOOT and BOOTICE 1.3.3.2 At MSFN there is topic USB Format Tool and UEFI_MULTI All my projects are now available for Download as Releases at wimb GitHub Download: USB_FORMAT and UEFI_MULTI and VHD_WIMBOOT and System_Info and MBR_Backup Manual: Win10_Install.pdfand Downloads: System_Info and Unattended_Eng.zip - Use UEFI_MULTI to Add WIM file to make Portable SSD booting from RAMDISK - filename = Win10XPE.wim - Use UEFI_MULTI to Add VHD file to make Portable SSD booting with FILEDISK - filename = W10x64_1909_F.vhd - Add ISO x64 file to NTFS System Drive used by WinNTSetup for Installing Win10x64 in VHD or hard disk - Boot from USB - After beep use F8 menu - Select Win10XPE-WIM or W10x64_1909_F.vhd in Boot Manager Menu - Use WinNTSetup x64 and ISO file for Installation of Windows 10 x64 in VHD or partition of internal SSD harddisk - Swith off Defender - In WinNTSetup use R-mouse menu - Local Windows Installations and Capture Wim to make Backup WIM file How to make Win10XPE WIM file for booting from RAMDISK Download: Win10XPE Builder - More Info: see Manual Download Win10_1909_English_x64.iso from TechBench Or using Windows-ISO-Downloader Tool Mount ISO with double-click and Copy the Content of the ISO to Folder Win10_1909_English_x64 on your Harddisk In WinBuilder > Build Core > Select Run ALL Programs From RAM to get WIM file with all Programs integrated In WinBuilder > Apps > System Tools DeSelect XPE Startup (when Selected build fails) In WinBuilder Select the Folder Win10_1909_English_x64 on your Harddisk and Start building with Play button Use Win10XPE\ISO\sources\boot.wim and Win10XPE\ISO\Boot\boot.sdi for booting WIM file from RAMDISK First copy both files to folder Win10XPE located on NTFS System Drive of Portable SSD Then use UEFI_MULTI to make Boot Manager entry for the WIM Boot Image file

Yes, I am happy too that VSS Capture using WimGAPI and having Defender switched off is bringing success Defender is slowing down the VSS Capture by at least a factor 7 so that it really safes a lot of time when Defender is disabled during Capture. I think that switching off Defender in case of VSS Capture can solve problems.

It is WinNTSetup Download Current Version 4.0, which has Local Windows Installations as Menu item available to Capture Wim ....

For the case of Win10x64 1909 Updated to version 10.0.18362.535 Online VSS Capture using WimGAPI + Defender Off is working very fast and After Apply is OK for logon. WIM File of Size 6.05 GB is Captured with Defender Off in less than 2 min (1:55 min) and with Defender On in 14 min

The logon failure for Applied Updated 1909 Win10x64 is sometimes solved by using VSS offline Capture, but it is not a reliable solution for the problem. @alacran After Windows Update I always reboot more times to be sure before Capture, but that did not solve the logon failure on Apply.

I have done a lot of testing now on what is causing the logon failure after Apply of Updated Windows 10 x64 Version 1909 on internal GPT SSD booting in UEFI Secure Mode. I can conclude now that this behaviour is not affected by Disable Hibernate Or BootMenuPolicy (Legacy / Standard) Or Local Account instead of Microsoft Account Or wimlib instead of WimGAPI. It turns out that just Windows Update of the fresh installed Windows 10 x64 1909 is causing this logon failure After Apply of a Captured WIM file of this Updated 1909 Windows x64 version. This Windows Update involves Windows explorer.exe to change from version 10.0.18362.387 into 10.0.18362.449 Strange enough first booting into Safe Mode solves the problem. Probably the Microsoft Security is too Severe ......

Booting in Safe Mode is working OK. After safe Mode then normal booting is working OK

Logon takes longer and icons are missing on taskbar. Windows Start button and My Computer icon on Desktop and Ctrl +Alt + Delete don't react. No way to get into Taskmgr ..... Finally Desktop screen disappears and I see mousepointer on black screen .....

Same results obtained for Version 4.0.1 What can be the reason that version 1909 after Windows Update followed by Capture and Apply fails for Windows logon (empty taskbar) ?

Fresh Install of Windows 10 version 1909 on internal SSD is working OK for Capture and Apply using 4.0 RC2. After Windows Update of that version then Capture and Apply results for me in failing logon of Windows 10. AFAIK the problem is not related to the program, but is caused by Windows Update of version 1909.

Ok, thanks for the Info It is working OK when Applied to real drive, but when Applied to VHD then booting fails with Error 0xC0000225

Thanks for the Info. Can you give some more info about Apply Mode Wimboot:WIMCOPY ?

The first tests are OK. What is besides offreg.dll new in 4.0 RC2 ?

System_Info - Updated to version 4.2 - Added 2 extra buttons Sys Info and DX Diag to use systeminfo.exe and dxdiag.exe of Microsoft

Thanks for version 4.0 RC1 which solves the Edit option for unattend.xml Did some testing with Apply of latest Win10 install.wim from Microsoft followed by wimlib Capture and then Apply in WimBoot mode using wimgapi. It seems the RC1 version corresponds to the 4.0 Beta 8 version and everything is working as expected and OK as long as the internal Windows\System32\WimBootCompress.ini is not modified.

System_Info - Updated to version 4.1 - Added 2 extra buttons to make Folder List and FileList from Selected Path and using Dir Command with Unicode support - Allows to keep multiple processes alive and visible System_Info is also available at Reboot.pro Forum

For Unattend the option right-click to open that file in notepad does NOT work anymore in 4.0 Beta 6/7/8

It is file bootmgr and file Boot\BCD that definitely need to be decompressed for booting VHD with grub4dos from RAMDISK in WimBoot mode. Decompressing the whole folder \Boot and \EFI is not needed and would take more free space from VHD and increase the time to load VHD into RAM. Booting with VHD in WimBoot mode from USB on various hardware can be improved when drivers are real files instead of WOF pointers. It is used to make a Portable Windows 10 Operating System in VHD booting in WimBoot Mode and located on Portable SSD connected via USB. But since Apply with wimgapi in WinNTSetup gives trouble in decompression of Windows 10 drivers, I think it is better NOT to add such option in WinNTSetup. We can use Apply with wimlib using WIM file Captured with wimlib and modified Windows\System32\WimBootCompress.ini if we want to have decompressed drivers in Windows 10 VHD booting in WimBoot mode.

Yes you are right. I went back to the original Windows\System32\WimBootCompress.ini of Microsoft with simple PrePopulateList that does not contain the line \Windows\System32\drivers\*.sys Then I did a Capture using WinNTSetup with wimlib and used the WIM file for Apply using wimgapi. As you say indeed in that case there is no driver problem with wimgapi anymore. It means however that we cannot PrePopulate with drivers in this way, which can be useful for booting VHD from USB in WimBoot mode on various hardware. Also files \Boot\BCD and bootmgr inside the VHD are WOF pointers, so that booting with grub4dos from RAMDISK using SVBus driver does NOT work anymore. For some cases it is desired to use modified WimBootCompress.ini and for that case wimgapi cannot be used in WinNTSetup, but wimlib will work fine. It is also a bit confusing that your Tools\WimBootCompress.ini file that has the line \Windows\System32\drivers\*.sys is not used at all in case of Windows 10. Only the WIM Internal Windows\System32\WimBootCompress.ini is used for Apply of Windows 10 with WinNTSetup.

Very Interesting In Beta 8 wimgapi results mostly in WIM backed driver files (WOF pointers) allthough the PrePopulate list instructs to make real files. In Beta 7 your code is doing better since then most driver files are indeed real files instead of WOF pointers. In both cases for some drivers the process fails and the error occurs when in the WIM file there is no iNode for these files. As conclusion we can say that wimgapi cannot be used in wimboot mode and wimlib is doing fine for this purpose. It would be better when for Capture the WimBootCompress.ini file in the WIM file is replaced by your Tools\WimBootCompress.ini file. That is what wimlib Capture is doing when --wimboot --config option is used. In this way the user has easy influence on what is occurring for Apply when the Internal Windows\System32\WimBootCompress.ini is used. As it is now the user can modify Tools\WimBootCompress.ini but these changes are not used during Apply.

Thanks for the Info. How come that in Beta 8 for Apply wimgapi + WimBoot most drivers become WOF pointers and in Beta 7 are real files, whereas both Internal and External WimBootCompress.ini files contain in the PrePopulateList a line \Windows\System32\drivers\*.sys ? I assume that in Beta8 you overruled WimBootCompress.ini for drivers\*.* to be WOF pointers, but I think it is better to have that action not hardcoded. It is nice as a test since it has helped me to see where wimgapi is failing since there is a bunch of files not having the WOF pointer. For Beta 8 the 3 troublesome drivers btfilter.sys and nvhda64v.sys and TeeDriverW8x64.sys are clearly visible in 7-zip (sorted for WOF) as being not a WOF pointer.

In Beta 8 for Apply wimgapi + WimBoot mode then most drivers are WOF pointers except for the troublesome drivers which files have normal size, but filled with byte zero. The bug is that somehow wimgapi is treating some drivers differently ..... It seems to me that only the Internal Windows\System32\WimBootCompress.ini is used. In what case and how is the file Tools\WimBootCompress.ini by WinNTSetup supposed to be used ? Capture with wimlib using --wimboot and --config replaces the internal WimBootCompress.ini file with the one used for Capture (property of wimlib) Such replacement of the internal WimBootCompress.ini does not seem to occur in WinNTSetup.

Thanks for Beta 8 Driver Problem with wimgapi + WimBoot still the same, e.g. btfilter.sys file has normal size but composed of only byte zero

The internal WimBootCompress.ini of the WIM file Applied with WinNTSetup is equal to my WimBootCompress.ini due to earlier Capture with wimlib in VHD_WIMBOOT Capture with wimlib using --wimboot and --config replaces the internal WimBootCompress.ini file with the one used for Capture (property of wimlib) WimBootCompress.ini