129 replies to this topic

[wimb]

I have integrated Capture capability into DMS and invite all users to test it.

Download here on Reboot.pro

 

 

Thanks for Adding to DMS program the option to Capture WIM files from selected disk drives.

 

It works quite well to Capture and Apply full Windows installed in VHD file mounted as drive,

but the Captured WIM file is NOT WimBoot compatible and cannot be Applied in WimBoot mode.

 

Also WimBoot Capture to make WimBoot compatible file does not work for me.

 

 DMS_Apply_WimBoot-2019-11-18_151443.png   16.29KB   0 downloads ==   DMS_Capture_WimBoot-2019-11-18_152758.png   17.63KB   0 downloads

[Tokener]

My dear friends, thank you for your warm feedback.
It is a great pleasure for me that you like the program.
I will try to improve the script further.
Adding BCDGui is one good idea.
 
Today I had a lot of work to do, so I could not answer instantly. So here is the delayed reply.
 
@Wonko

The experiment needed is the following:
1) get to the point of a "capturable" disk with only SYSTEM and SOFTWARE hives in \Windows\System32\Config
2) make a dd-like copy of:
a. the MBR (you never know)
b. the bootsector (or $Boot file)
3) make a "normal" copy/backup of BOTH SYSTEM and SOFTWARE hives from \Windows\System32\Config
4) format the volume
5) restore the copy/backup of BOTH SYSTEM and SOFTWARE hives to \Windows\System32\Config
6) try capturing the disk (it should fail as in your report with error 87)
7) restore the dd-like copy of the bootsectror
8) try again captuing the disk (what happens? [1])

I worked through the list of steps, but not with success. the error 87 was the result after step 8.

 
Then I wanted to find out which files are indispensable for the creation of an image.
So I gradually deleted all files from the hard drive / partition until only a few were left, without which no image could be created.

 
Here is the list of indispensable files:

Spoiler

\Windows\System32\ntoskrnl.exe
\Windows\System32\config\SYSTEM
\Windows\System32\config\SOFTWARE

 

After backing up these files I created a new vDisk with NTFS partiton and copied these files there, to original path. And again capturing succeeded.

 

@wimb

 

It works quite well to Capture and Apply full Windows installed in VHD file mounted as drive,

but the Captured WIM file is NOT WimBoot compatible and cannot be Applied in WimBoot mode.

I haven't yet tried creation of WIMBOOT system, so I can not give any advice.

But I see you are using a version of dism which is of older kind.

Sure you have already tested newer ones, but I do not want to leave it unmentioned.

 

Kind regards   T.

[wimb]

ReTokener, on 18 Nov 2019 - 11:14 PM, said:

I haven't yet tried creation of WIMBOOT system, so I can not give any advice.
But I see you are using a version of dism which is of older kind.
Sure you have already tested newer ones, but I do not want to leave it unmentioned.

Just to let you know that the latest version of dism does NOT solve the problem.
Still NOT being able to Capture WIM file that is WIMBOOT compatible.

Also it is not possible now to Apply in WIMBOOT mode a WIM file that is not marked as WIMBOOT compatible (solution see below).

 Capture_DMS-2019-11-19_055503.png   17.87KB   0 downloads  Capture_DMS-2019-11-19_055816.png   18.11KB   0 downloads

WinNTSetup uses dism wimgapi to Capture WIM file that is NOT marked as WIMBOOT compatible.
In VHD_WIMBOOT I can use such Captured WIM files with wimlib for Apply in WIMBOOT mode by allowing WIM files that are not marked as WIMBOOT compatible.

In WinNTSetup such WIM files can be Applied by dism in WIMBOOT mode by letting dism SKIP the WimBoot check.

JFX gives as advice for Apply with dism in WIMBOOT mode to Add the following line to the AutoIt program:

EnvSet("WIM_SKIP_WIMBOOT_CHECK", "1")

Another problem of dism is that it cannot be used for Apply in WIMBOOT mode with a modified WimBootCompress.ini file which can make the drivers to be uncompressed.
In that case wimgapi is making mistakes in uncompressing drivers.
For a Portable Win 10 operating system in VHD booting in WIMBOOT Mode from USB and located on Portable SSD, 

it is desired to have all drivers uncompressed available in the VHD, so that we can easily boot on various hardware.

This wimgapi problem is best solved by using wimlib in WIMBOOT mode as done in VHD_WIMBOOT instead of using dism.

[Tokener]

Hi wimb

thanks for detailed response.

 

I take a look as soon as possible.

 

cu   T.

[alacran]

Of course the main idea for wimboot VHDs is PORTABILITY and without a custom WimbootCompress.ini it is not possible.

 

I have been runing some tests with several different Dism versions (other were already tested by wimb), some of them are capable to apply a VHD on Wimboot mode when the *.wim was previously captured by wimlib-clc as wimboot so the *.wim has the wimboot flag , but during boot some drivers (like svbus64.sys, required to Ramboot using grub4dos), are corrupt and the VHD do not boot (as filedisk or as Ramdisk), so I think it is better to remove on DMS the option for Wimboot on Capture and Apply, to avoid troubles to the users.

 

Attached my DismMountService-log

 

The wimboot mode is now deprecated by MS:

 

 

/WIMBoot Use /WIMBoot to append the image with Windows image file boot (WIMBoot) configuration. This only applies to Windows 8.1 images that have been captured or exported as a WIMBoot file. This feature isn't supported in Windows 10.

Source: https://docs.microso...ine-options-s14

 

 I understand This feature isn't supported in Windows 10 = Not on the OS or on anything related to it as Dism.

 

And as wimb and I already know from WinNTSetup there is no way to fix it (when using a custom WimbootCompress.ini), the issue is on Dism, (so nothing can be done), only way is using wimlib-imagex for this task.

 

Wimboot was replaced on 10 with Compact mode, so better make a message on DMS for the users saying:

Compact mode only applies when running and deploying 10, for now.

 

 

/Compact Applies an image in compact mode, saving drive space. Replaces WIMBoot. For Windows 10 for desktop editions (Home, Pro, Enterprise, and Education) only.

Source: https://docs.microso...ine-options-s14

 

Latter if you want, with some more time I think I can help you to implement it on the host and the guest OSs, when one or the other OSs are older than 10. I have an script to add wofadk to ChrisPE 7 and 8.0 builds, and also send you a pm on MSFN about this 2 subjects.

 

alacran

Attached Files

•  DismMountService-log.7z   1.06KB   1 downloads

[Wonko the Sane]

 

 
Here is the list of indispensable files:

Spoiler

\Windows\System32\ntoskrnl.exe
\Windows\System32\config\SYSTEM
\Windows\System32\config\SOFTWARE

 

After backing up these files I created a new vDisk with NTFS partiton and copied these files there, to original path. And again capturing succeeded.

 

Very good .

 

So the issue wasn't with the content of SOFTWARE and/or SYSTEM but with the missing ntoskrnl.exe.

 

Next experiment, full bluff ;

 

1) create a new VHD, partition, format, mount (let's say volume gets drive letter F: )

2) create a folder F:\Windows\System32\ and a folder F:\Windows\System32\config

3) create a few text files with "random" contents, in a command window:

ECHO Mickey Mouse>F:\Windows\System32\ntoskrnl.exe
ECHO Donald Duck>F:\Windows\System32\config\SOFTWARE
ECHO Goofy>F:\Windows\System32\config\SYSTEM

4) try capturing the .vhd

 

Wonko

[Tokener]

Good idea

 

Next experiment, full bluff

Done, but now we have a new "flimsy excuse":

Error: 1016

 

regards   T.

[alacran]

It seems it is related to a corrupt registry:

 

 

Method 2. Restore Windows Registry from Backup.

The next method to fix the dism error 1016 (An error occurred while attempting to access the image), is to restore the Windows registry from the 'RegBack' folder. *

* Info: The 'RegBack' folder, (full path=Windows\System32\Config\RegBack), is the location where Windows stores automatically a backup of the registry files whenever the machine is starting up.

Source: https://www.repairwi...e-image-solved/

 

alacran

[Tokener]

dism realizes a broken registry, makes sense.

now I replaced ntoskrnl.exe with a dummy-file: (leaving valid SYSTEM and SOFTWARE)

Error: 2

[Tokener]

same test with dism 10.0.18362.1

ntoskrnl.exe is a dummy-file: (leaving valid SYSTEM and SOFTWARE)

Error: 1812

[Wonko the Sane]

I would try going back from Errors 2 and 1812.

The solution for both should be to use a "real" ntoskrnl.exe (leaving the "real", valid SOFTWARE and SYSTEM)

Now, what defines a "real" ntoskrnl.exe?

It cannot logically be the version, maybe the check is only about it being a PE executable.

I mean, what if you try with a "real" ntoskrnl.exe from (say) 7 or 8 (or Vista )

Then what if you try with *any* executable renamed to ntoskrl.exe

 

If any of the above work, then it would be time to try faking the SOFTWARE and/or SYSTEM.

 

As an example you could take a \boot\BCD (which is in itself a valid Registry Hive) and make two copies of it, saving them as \Windows\System32\config  (SOFTWARE and SYSTEM).

I doubt that it would work, as a lot of MS software has internally the ability to read/access Registry hives, so it is likely that a given key is checked/read.

So the next step would be to use something *like* Regmon or Procmon to trace the accesses to the two Registry hives by DISM,

 

Wonko

[Tokener]

replacing ntoskrnl.exe with regedit.exe returns:

Error: 50

[Tokener]

replacing SYSTEM / SOFTWARE with BCD return:

Error: 2

[wimb]

It seems it is related to a corrupt registry:

 

Source: https://www.repairwi...e-image-solved/

 

 

The C:\Windows\System32\config\RegBack folder as mentioned in Method 2 is in practice empty , since Windows 10 does not make automatically a registry backup in RegBack folder 

 

Registry Backup Portable is the way to make automatically a backup of the Windows registry in C:\RegBackup folder, which is indeed quite useful for Windows repair 

[alacran]

I didn't know that Win10 does not make automatically a registry backup in RegBack folder.  Just opened the folder and in fact it is empty.

 

Thanks for the info and the link.

 

alacran

[wimb]

More Info on Microsoft Registry Backup is here

 

Starting in Windows 10, version 1803, Windows no longer automatically backs up the system registry to the RegBack folder. 

......
This change is by design, and is intended to help reduce the overall disk footprint size of Windows. 

 

Come on ....They blow up the footprint size all the time and now they are suddenly worried about making a small size registry backup of 130 MB .....

 

Also the RegBack that Windows can make is incomplete since it contains only 5 registry files instead of 13 backup registry files made by Registry Backup Portable

Windows does not make a backup of drivers and components registry and of the 6 User Registry Files .....

 

 RegistryBackup-2019-11-20_180038.png   54.59KB   0 downloads

[antonino61]

Thanx for the regbackup tool, wimb.

[wimb]

Thanks ReTokener for making available DismMountService_191119 which allows to Apply in WIMBOOT mode.

 

The Captured WIM file contains WimBootCompress-W10X.ini as file Windows\System32\WimBootCompress.ini to avoid wimgapi mistakes.

 

Best performance in Win10XPE environment - Apply of WIM file in WIMBOOT mode on VHD in 35 seconds with used space = 347 MB 

 

 DMS_Apply_WIMBOOT_OK-2019-11-21_184810.png   102.43KB   0 downloads

[Tokener]

Hi wimb, you are welcome.

I see you are using dism 10.0.17134.1

What do you think is the most compatible dism version?

 

Regards   T.

[wimb]

I see you are using dism 10.0.17134.1

What do you think is the most compatible dism version?

 

 

That is simply the dism version of my Win10XPE which is working OK.

 

Dism version 17763 is also OK, but dism 18362 of Win10 1909 will fail in case of FFU Capture with Error 50

[Tokener]

I wonder how MS has managed to install a wimboot system if dism could not create a wimboot image?

 

Regards   T.

[wimb]

I wonder how MS has managed to install a wimboot system if dism could not create a wimboot image?

 

 

WIMBOOT was developed for Windows 8.1 and at that time dism could Capture a wimboot image.

 

In Windows 10 dism does not support wimboot anymore, but dism Apply in wimboot mode is still possible if we use dism SKIP the WimBoot check

 

Apply and Capture in WIMBOOT mode is supported quite well in wimlib, which is also used in VHD_WIMBOOT

[Tokener]

Thanks for the fast response.

 

(...) at that time dism could Capture a wimboot image.

Since we can switch to different dism versions isn't it possible to use the specific dism-version which worked?

(dism v.6.2.9200.16384 didn't work for me)

 

Regards   T.

[alacran]

I wasn't able to find a Dism version for 10 that works fine, I already tested it, see: http://reboot.pro/to...e-4#entry213321

 

alacran

[alacran]

If you have plans to create a Windows 10 wimboot install by means of DismMountService, to avoid issues during applying on wimboot mode before capturing a WIM image it is recommended to do the following:

 

1 .- Install Windows 10 OS on a VHD fixed size VHD (see NOTE-4 and NOTE-5) by means of DismMountService, you will have to create a entry on the BCDs of your PC located on EFI\Microsoft\Boot\BCD and/or Boot\BCD, now we can use DMS to create the boot files/folders and edit them with BootIce using as a guide the pictures located on:

"WimBootCompress Installs\BCDs\On PC"

 

If you prefer you can do it also manually, see: https://docs.microso...ions-techref-di

 

Download attachment with the WimBootCompress.exe and pictures on folder BCDs.

 

2 .- Boot to the Windows 10 OS on the VHD that will be used as source for create the WIM image file.

3 .- Install all your required drivers, Office and other software, but DO NOT install SvBus driver.

4 .- Run from the VHD WimBootCompress.exe, it is a SFX file (selfextracting file), it will copy WimBootCompress.ini to C:\Windows\System32 folder overwriting previous version (if any). Run again DMS from the VHD and this time installing the boot files/folders to the VHD (wich is C: in this moment), and edit them with BootIce using as a guide the pictures located on "WimBootCompress Installs\BCDs\On VHD"

 

WimBootCompress.ini into the SFX file:

Spoiler

; This is the inbox configuration file used for deploying or capture a
; WIMBoot system. Please do not remove this file because WIMCaptureImage 
; and WIMApplyImage will fail if WIM_FLAG_WIM_BOOT flag is specified.

[CompressionExclusionList]
ntoskrnl.exe

[PrepopulateList]
bootstat.dat
*winload.*
*winresume.*
wof.sys
\Windows\System32\Config\SYSTEM
\Windows\System32\PlatformManifest\*
\bootmgr
\Boot\BCD

[ExclusionList]
\MSOCache\*
\Recovery\*
\$bootdrive$
\$dwnlvldrive$
\$lsdrive$
\$installdrive$
\$Recycle.Bin\*
\bootsect.bak
\hiberfil.sys
\pagefile.sys
\ProgramData\Microsoft\Windows\SQM
\System Volume Information
\Users\*\AppData\Local\GDIPFONTCACHEV1.DAT
\Users\*\NTUSER.DAT*.TM.blf
\Users\*\NTUSER.DAT*.regtrans-ms
\Users\*\NTUSER.DAT*.log*
\Windows\AppCompat\Programs\Amcache.hve*.TM.blf
\Windows\AppCompat\Programs\Amcache.hve*.regtrans-ms
\Windows\AppCompat\Programs\Amcache.hve*.log*
\Windows\CSC
\Windows\Debug\*
\Windows\Logs\*
\Windows\Panther\*.etl
\Windows\Panther\*.log
\Windows\Panther\FastCleanup
\Windows\Panther\img
\Windows\Panther\Licenses
\Windows\Panther\MigLog*.xml
\Windows\Panther\Resources
\Windows\Panther\Rollback
\Windows\Panther\Setup*
\Windows\Panther\UnattendGC
\Windows\Panther\upgradematrix
\Windows\Prefetch\*
\Windows\ServiceProfiles\LocalService\NTUSER.DAT*.TM.blf
\Windows\ServiceProfiles\LocalService\NTUSER.DAT*.regtrans-ms
\Windows\ServiceProfiles\LocalService\NTUSER.DAT*.log*
\Windows\ServiceProfiles\NetworkService\NTUSER.DAT*.TM.blf
\Windows\ServiceProfiles\NetworkService\NTUSER.DAT*.regtrans-ms
\Windows\ServiceProfiles\NetworkService\NTUSER.DAT*.log*
\Windows\System32\config\RegBack\*
\Windows\System32\config\*.TM.blf
\Windows\System32\config\*.regtrans-ms
\Windows\System32\config\*.log*
\Windows\System32\SMI\Store\Machine\SCHEMA.DAT*.TM.blf
\Windows\System32\SMI\Store\Machine\SCHEMA.DAT*.regtrans-ms
\Windows\System32\SMI\Store\Machine\SCHEMA.DAT*.log*
\Windows\System32\sysprep\Panther
\Windows\System32\winevt\Logs\*
\Windows\System32\winevt\TraceFormat\*
\Windows\Temp\*
\Windows\TSSysprep.log
\Windows\winsxs\poqexec.log
\Windows\winsxs\ManifestCache\*
\Windows\servicing\Sessions\*_*.xml
\Windows\servicing\Sessions\Sessions.back.xml

; [PinningFolderList]
; \Windows\System32\config
; \Windows\System32\DriverStore
; \Windows\WinSxS

[CompressionFolderList]
\Windows\System32\WinEvt\Logs
\Windows\Installer

 

5 .- Reboot to your main full OS on the PC or Win10XPE_x64, mount the VHD and capture the OS (as a standard WIM image) by means of DismMountService.

6 .- Dismount the VHD, create a new fixed size VHD and install from previously captured WIM, don't forget to select Wimboot mode when applying the OS on your virtual drive.

7 .- If you made a wimboot install on a VHD, It is recommended to make a FFU image of the VHD right now before unmount it, this will let you rebuild the VHD in seconds if required.

NOTE-1: This is WimBootCompress-W10X.ini renamed, taken from the great tool made by wimb: VHD_WIMBOOT

NOTE-2: The main pourpose of this modified WimBootCompress.ini is to reduce the size on MB used on the target drive.

NOTE-3: The installs made by means of DismMountService are NOT valid for RAMBOOT (only valid for CSM/MBR, not valid for UEFI), even if SvBus driver was previously installed on the source OS, since the SvBus driver will be a pointer to the source WIM file and grub4dos requires it uncompressed. If you want to make your new wimboot install to be RAMBOOT capable do as on OPTIONAL:

NOTE-4: For faster booting it is also possible to use a dynamic VHD (expandable), since the begining, it is also capable to RAMBOOT after installing SvBus driver as on OPTIONAL but it can't RAMBOOT if compressed by lz4.

NOTE-5: The FFU previously created (on No. 7 and also on No. 8) from a fixed size VHD allow us to Apply it to a new created dynamic VHD,

OPTIONAL: RAMBOOT

8 .- After booting your wimboot VHD for the first time install SvBus driver, and reboot to your main full OS on the PC or Win10XPE_x64, mount the VHD and modify the BCDs on Boot\BCD on your PC and into the VHD as required, no need to worry about the BCDs on EFI\Microsoft\Boot\BCD because RAMBOOT is only possible on CSM/MBR, see attached pictures on folder BCDs, make a new FFU image and dismount it.

9 .- Now it is time to boot as RAMBOOT by means of grub4dos, assuming you have on your BCD an entrance for \grldr.mbr, just add to your menu.lst the following:

 

Spoiler

# VHD and source WIM created on internal drive.

title 10x64-WB.vhd - SVBus RAMDISK - 1536 MB - 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


# VHD and source WIM created on external drive.

iftitle [if exist (hd0,1)/10x64-WB.vhd] (hd0,1)/10x64-WB.vhd - SVBus RAMDISK - 1536 MB Max. - map as (hd-1) for WIMBOOT
map --top --mem (hd0,1)/10x64-WB.vhd (hd-1)
map --hook
root (hd-1,0)
chainloader /bootmgr

 

10 .- A fixed size VHD allow us to compress it using lz4_compressor, see: http://reboot.pro/fi...compressor/thenour menu will be like this:

 

Spoiler

# VHD and source WIM created on internal drive.

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


# VHD and source WIM created on external drive.

iftitle [if exist (hd0,1)/10x64-WB.vhd.lz4] (hd0,1)/10x64-WB.vhd.lz4 - SVBus  RAMDISK  - 1536 MB Max. - map as (hd-1) for WIMBOOT
map --top --mem (hd0,1)/10x64-WB.vhd.lz4 (hd-1)
map --hook
root (hd-1,0)
chainloader /bootmgr

 

 

From: http://reboot.pro/to...-faster-on-ram/

 

 

If Rambooting from a fast device as an SSD use expandable VHDs, they have very good speed and a resonable saved espace, do no require any additional compression, they are capable to Ramboot and also can be booted from Windows bootmanager, so it is not a big issue if they can't boot as Filedisk using grub4dos.

If Rambooting from a not so fast device as an SSD, we have the alternative to use LZ4 compressed VHDs, wich are the faster option and also save more espace than any other option, but they are only usefull for Rambooting, we can not boot them as Filedik using grub4dos or from Windows Bootmanager, this limitations also apply to GZ compression.

 

 

Best Regards
 

alacran

Attached Files

•  WimBootCompress Installs-v2.7z   706.33KB   10 downloads