1025 replies to this topic

[Wonko the Sane]

 

FOR %1 IN (*.DLL) DO REGSVR32 /S %1

 

 

Off-topic note, isn't it fantastic that in 2022 we are still fixing the stupid latest Windows with one of the oldest tricks of the trade? (this dates back to - good ol' - NT 3.5-NT4.00 times)

 

JFYI, maybe of inspiration for your experiments:

http://reboot.pro/in...c=3717&p=154017

 

Wonko

[gbrao]

With Windows created using Wimbs tools, is User Acc Control (UAC) active ?

 

I don't use these tools just want to know.

 

NTLite has the option to remove UAC and I would like to remove it in my RAMboot Windows.

[wimb]

With Windows created using Wimbs tools, is User Acc Control (UAC) active ?

 

I don't use these tools just want to know.

 

NTLite has the option to remove UAC and I would like to remove it in my RAMboot Windows.

 

My Tools don't make changes for User Account Control. That means Default for Fresh Install it is UAC=On but you can scwitch Off if desired.

[alacran]

JFYI

 

I have being running some tests trying to make our Mini 10 2004 VHDs use the less possible space but without editing Win_Debloat-41 and Win_Reduce_Trusted-61 for this task.  I remembered Win 10 2004 Wof.sys driver is more permisible than previous versions, then I decided to use its internal current WimbootCompres.ini and add just very minimal modifications to it (just the minimal needed to fit our requirements).

 

WimBootCompress.ini for Mini-10-2004.vhd(s)

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.
; Version for Mini-10-2004.vhd(s) by alacran

[CompressionExclusionList]
ntoskrnl.exe

[PrepopulateList]
bootstat.dat
*winload.*
*winresume.*
wof.sys
\Windows\System32\pwdrvio.sys
\Windows\System32\pwdspio.sys
\Windows\System32\Config\SYSTEM
\Windows\System32\PlatformManifest\*

[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
\bootmgr
\BOOTNXT
\Boot
\EFI
\x-*Boot
\x-*EFI

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

 

 

Also attached for your convenience as: WimBootCompress-for-10-2004.7z Password = alacran

 

The results using this version of WimbootCompress.ini are good on Compact LZX installed VHDs, about 160+ MB less used space just after installed, but on Wimboot mode installed VHDs, the result is impresive, as we end up with 84.4 MB used space just after installed. And you can see the results and comparative in the attached photos, where left image is just installed, and right image is after first filedisk boot.

 

Please test this approach as on it all drivers remain compressed or are only pointers, so far it has worked fine to me, but more tests on different hardward are required.

 

Info from WOF_Compress:

 

; LZX ; G:\Windows\System32\drivers\svbusx64.sys

; WIM-Backed ; G:\Windows\System32\drivers\svbusx64.sys

 

NOTE: We need to remember the just installed used space, is permanent every boot and it's the amount of info that will be loaded to Ram, as long as we only Ramboot the VHDs, once the VHDs are booted the OS creates a lot of new archives and also overwrites a bunch of files, so our LZX compacted files on VHDs Compact LZX installed, or 0 bytes pointer files in case of Wimboot installations will be replaced with full size uncompressed files, increasing the used size into the VHD, this is volatile if Rambooting, but permanent if filedisk booting.

 

If using lz4_compressor we can reduce the size our LZX Compacted Ramboot VHDs, this gives us following benefits: 

1. Less space required to store the unchanged VHDs for Ramboot.
2. Faster to load on Ram.
3. It can be decompressed anytime to have a new fresh uncompressed VHD to replace our old uncompressed VHD.

In case of Wimboot VHDs lz4 compressed, only the 2 first apply as we require to also keep the coupled WIM file.

 

Mini-10x64-LZX.vhd = 2 GB     Mini-10x64-LZX.vhd.lz4 = 1.43 GB

 

Mini-10x64-WB.vhd = 800 MB   Mini-10x64-WB.vhd.lz4 = 138 MB     10x64-2004.wim = 1.16 GB

 

alacran

Attached Thumbnails

• 
• 

Attached Files

•  WimBootCompress-for-10-2004.7z   1.17KB   1362 downloads

[wimb]

WimBootCompress.ini for Mini-10-2004.vhd(s)

 

Using your WimBootCompress.ini seems to be a good Space Saver.

 

It means we need to have much less files UnCompressed for Compact mode and you say it also woks for WimBoot mode.

 

Does it mean that I can safely replace the existing VHD_WIMBOOT\makebt\WimBootCompress.ini with your version and that it can be used in general ?

 

Or is it meant that your WimBootCompress.ini is only used for making Mini-10x64.vhd from 2004 Win10x64 ?

 

I thought in the past we conluder that drivers\*.sys must be uncompressed 

[alacran]

As said: I recommend it for 10 2004 and newer 10, on 11 requires testing, the old Wof.sys driver version in older 10 versions is not so permisive.

 

I have tested this file on 10 2004, and all working fine so far, and I'm asking to test it on newer versions (Win11).

 

In case of older OSs, it is better to keep using the usual WimbootCompress.ini version we have for general use, where all drivers are uncompressed, as the WofADK.sys driver used by WinNTSetup, and installed by it into 7 and 8.x OSs, is an old version that will not work the same as the new versions of wof.sys

 

Yes, we conclude that drivers\*.sys must be uncompressed at that time, to make easier the portability, and it has worked very fine so far, but it seems newer Wof.sys driver version works better, as I have tested the VHDs Ramboot even if SVBus is compressed or a pointer, something we never dreamed before.

 

I think you were writing when I was editing my previous post with following info from WOF_Compress:

 

; LZX ; G:\Windows\System32\drivers\svbusx64.sys

; WIM-Backed ; G:\Windows\System32\drivers\svbusx64.sys

 

Also before anybody ask, if following items are excluded from capture as they are under [ExclusionList] section, it doesn't make sence to include them in [PrepopulateList] section as they do not exists into the captured WIM file.

 

\bootmgr
\BOOTNXT
\Boot
\EFI
\x-*Boot
\x-*EFI

 

EDIT: And anyway as the first 4 are created once the installation is finished, they are real size files since created.

 

alacran

[wimb]

OK thanks for explanation. More testing needed for Mini from Win11x64 and if Booting from USB on other hardware still works ....

[antonino61]

well, testing this one too. btw, Last night I realized that a combination of vhd_wimboot for capturing and winntsetup for reapplying gives the vhd a boost in speed and a reduction in space used. Attaboy wimb and alacrán. now trying to see if this new wimbootcompress does any better in either stage, both stages or neither stage. in a bit. 

 

Well, school meeting over with a little earlier, so I was able to test it with winntsetup and, I have to admit I've had no smaller vhd ever before (less than 1.40gigs).

[antonino61]

well, folx, sorry if I insist, but, despite I have pledged to abide by alacrán and wimb's suggestions to test the minimal version of miniwindows (which I definitely will continue to), I keep thinking that considering only the generalized, barely minimal, version of it is way below its own potential (u really wanna see how many would like to have this up and running if only they could do it so easily as it seems to them when they see normal everyday operations). there is really not much difference now between the minimal version and one catering for just a few more things), which could be added on a modular basis. I have gathered some sort of informal textual and factual database of dlls needed for this, that and/or the other additional software (many of them dlls are even overlapping across the sections, so to speak). it seems like a pity to just keep it all in store. It could even be considered an eco-friendly solution - so little space as one needs, no more, no less. Sorry again if I got carried away, but I cannot stop enthusing at it all!

[alacran]

About the new WimBootCompress.ini version.

 

Just to put some info together I will quote this post:

Spoiler

 

Posted 24 September 2020 - 11:46 PM

 

alacran, on 24 Sept 2020 - 10:28 PM, said:

Also it is possible to install Win10XPE_x64 directly on a Compact mode VHD, using wimlib-clc and the boot.wim file, only required is edit the Wimboot attribute of the image. As it already contains its own version of WimBootCompress.ini

alacran

 

It also boots fine this way, using its own version of WimBootCompress.ini, as I have already tested, VHD used size is a little smaller, now it is 948 MB

 

And JFYI wimlib gives a message about some files only compacted as 4K for compatibility, something already mentioned here: http://reboot.pro/to...e-3#entry216201

 

alacran
 

Attached Thumbnails

• 
• 

 

So since this date (2020-Sept-24) I tested the Win10 internal WimbootCompress.ini and it worked fine, having all drivers compressed.

 

And also this post:

Spoiler

 

Posted 19 September 2020 - 11:45 PM

 

JFYI:

 

I saw this topic on wimlib Forum some time ago, but forgot to comment it on this Forum:

(The comments apply to Win10 1903 and newer)

 

Topic: https://wimlib.net/f...c.php?f=1&t=444

 

I will quote it here for your convenience:

 

Spoiler

 

--compact bootloader restrictions lifted in 1903 and beyond

•  

Post by Googulator »

Mon May 13, 2019 8:57 pm

Wimlib currently maintains a hardcoded list of files that must never be compressed beyond XPRESS4K when doing a compact deployment.
As of Windows 10 version 1903, this is obsolete.
1903 can boot fine with both winload.efi and ntoskrnl.exe manually compressed as LZX, according to my own testing. (This required a bit of trickery, as Windows' compact.exe refuses to compress any file containing "winload" in its name - I ended up copying winload.efi to bootload.efi, compressing that, and editing BCD to point to bootload.efi instead of winload.efi. No such restriction exists for ntoskrnl.exe.)

Also in 1903, dism's /Compact seems to use XPRESS8K for all files, including ntoskrnl and winload.

I'm not sure which build introduced this change, but at least in 18362 and up, the blacklist can be safely ignored, and everything compressed with the user's selected compression mode.

 

And this is synchronicity (Erig Biggers) wimlib author answer:

 

Re: --compact bootloader restrictions lifted in 1903 and beyond

•  

Post by synchronicity »

Fri Jun 05, 2020 1:33 am

Fixed by commit 4ab624f1529c

 

Then the internal list of wimlib-imagex, ([he calls it black list] used to control/exclude critical files compression during Compact mode Apply), was updated on commit 4ab624f1529c, but from the Downloads page we can see there is not jet a new release after the commit date, so I assume this will be implemented on a future release, see:

 

Spoiler

Downloads
File      Released     Size     Downloads/week
wimlib-1.13.3-BETA1.tar.gz     2020-06-02    1028 KB    12
wimlib-1.13.3-BETA1-windows-i686-bin.zip    2020-06-02    897 KB    9
wimlib-1.13.3-BETA1-windows-x86_64-bin.zip    2020-06-02    882 KB    14
wimlib-1.13.2.tar.gz     2020-05-24    1031 KB    354
wimlib-1.13.2-windows-i686-bin.zip     2020-05-24    897 KB    113
wimlib-1.13.2-windows-x86_64-bin.zip     2020-05-24    881 KB    248
wimlib-1.13.1.tar.gz     2019-05-07    1033 KB    8
wimlib-1.13.1-windows-i686-bin.zip     2019-05-07    858 KB    28
wimlib-1.13.1-windows-x86_64-bin.zip     2019-05-07    873 KB    28

 

 

 

alacran

 

So this means since Win10 1903 the wof.sys driver is capable to read winload.efi and ntoskrnl.exe manually compressed as LZX.

 

And latter a new version (v1.13.3 on 2020-10-27) of wimlib-imagex made possible to apply our desired compression during deploying the selected Win10 (v1903 and newer) WIM index image file.

 

So far, I didn't know when exactly all pieces became together, to let us make use all the potential of this new approach, but the point is: it is working fine now.

 

And that WimbootCompress.ini can be used since Win10 1903, not recomended as some versions before 2004 has certaing USB issues, I can confirm it fails a lot if running a WinPE based on 10 before 2004 and we use USB_FORMAT by wimb to format an USB device.    Better avoid to use Win10 1903.

 

I urge all readers to test this new version of WimbootCompress.ini booting from a USB device, and report back. Additional feedback is required, to make sure it works fine booting from USB 3.x with different PCs hardware.

 

I suggest to test this new version of WimbootCompress.ini booting from a USB device only if using USB 3.x devices, that are really fast, not cheap unknown devices of dubious quality and speed.

 

alacran

[alacran]

@ wimb

 

My friend, I hope I'm not asking too much, but I would like to have on VHD_WIMBOOT_Trusted an additional button (or similar) for select to use the new proposed version of WimbootCompress.ini

 

This will make easier for the users to manually and consciously select the new proposed version of WimbootCompress.ini, or use the standard behaviour of the program.

 

Also this way if for any (so far) unknown reason the new approach fails to boot in some scenario, there is still available the good old approach, (that so far has proven to be very reliable), to let users make this time a new traditional build.

 

alacran

[wimb]

Update VHD_WIMBOOT_Trusted-67

 

Download:  from wimb GitHub  -   VHD_WIMBOOT_Trusted-67

 

Download File E = Encrypted PassWord = bootwimb

 

Manual:   VHD_WIMBOOT.pdf

 

- Added Button WBC to Select version of WimBootCompress.ini e.g. WimBootCompress-Mini.ini - Thanks to alacran

 

"Select WimBootCompress.ini - Default Or Mini "

" Default = PrePopulate with Drivers for Portability "

" Mini     = PrePopulate Minimal for Smaller Size "

" Captured WIM in WimBoot Mode gets WimBootCompress.ini File "

" Effective for Apply in Compact or WimBoot Mode with wimlib "

 

Making use of WimBootCompress-Mini.ini is a Good Space Saver and is OK for Win 10/11 x64,

but Portability of Booting on other hardware is Unknown and has to be proven.

 

WimBootCompress-Mini.ini is slightly modified as compared to the version given by alacran

by adding to the  [PrepopulateList] section

wofadk.sys

\bootmgr

\BOOTNXT

\Boot\*

\EFI\*

 

Sure we don't need these entries for our Mini-10x64 made with VHD_WIMBOOT

but if someone Captures a WIM file of Win7/8 or Win 10/11 with the WBC Mini Setting

and / or uses that WIM file for APPLY with wimlib-clc or other software then these entries are important ....

These entries have no space effect for the UsedSize in our Mini-10x64 VHD and are a good protection against future failure issues ....

 

[alacran]

 

Update VHD_WIMBOOT_Trusted-67

 

WimBootCompress-Mini.ini is slightly modified as compared to the version given by alacran by adding to the  [PrepopulateList] section

wofadk.sys

\bootmgr

\BOOTNXT

\Boot\*

\EFI\*

 

Sure we don't need these entries for our Mini-10x64 made with VHD_WIMBOOT

but if someone Captures a WIM file of Win7/8 or Win 10/11 with the WBC Mini Setting

and / or uses that WIM file for APPLY with wimlib-clc or other software then these entries are important ....

These entries have no space effect for the UsedSize in our Mini-10x64 VHD and are a good protection against future failure issues ....

 

 

Excuse me my friend, but you are wrong this time.

You can't extract files (as full size, compressed or as a pointer) from a WIM image if they are not there.

 

[ExclusionList] section explicity avoids to copy to the WIM image the following files during capture:

 

\bootmgr
\BOOTNXT
\Boot
\EFI

 

List this files in [PrepopulateList] section will not make them appear magically.

 

So to get your desired efect you need to also delete those files from [ExclusionList] section in all versions of WimbootCompress.ini file used in your program.

 

They were included in the past in [ExclusionList] section to avoid certain issue with grub4dos for UEFI and Rambooting (the no handle... if you remember)  but as far as I know, that issue was fixed.  I think we could check if that issue is really not present anymore, and then if all goes fine decide to eliminate them from the [ExclusionList] section.  Which will simplify other things too.

 

Just to let you know into download of Wimlib-clc program by Tokener, there is a folder wimbootcompress with this two files inside:

 

WimBootCompress-for-VHD_WIMBOOT.ini   >>>   Self explicative

 

WimBootCompress-by-alacran.ini   >>>   I recommend to use this one to make (standard installed, not VHD) OS backups, only difference is the mentioned files are not listed in [ExclusionList] section, as I have found several PCs (MBR formated), where the user installed the Boot files/folders in same Windows parition.

 

alacran

[alacran]

A few more info about how to easy verify the issue is not present anymore:

 

I think we could check if that issue is really not present anymore, and then if all goes fine decide to eliminate them from the [ExclusionList] section.  Which will simplify other things too.

 

If I remember well we started having this issue when we used our previous WIM files captured from NTFS single partition VHDs for MBR (having boot files/folders in same NTFS active partition).

 

When installing this WIM files in new created 2 partitions (FAT-32 + NTFS) VHDs, a new set of boot files/folders was created by your program in the new FAT-32 partition that we never used before (that was fine in fact), but at the same time the original boot files/folders were extracted into NTFS partition, then caused for a wrong code in G4E this made the VHDs unbootable, and the issue message NO HANDLE... bla, bla, bla appeared, and you fixed it first renaming the folders to \x-*Boot and \x-*EFI, and I suggested latter to add the files to the list under [Exclusion List] section and it worked very fine.

 

AFAIK this issue was latter fixed by modifying the G4E code to start looking for the bootable files in first partition.  But we didn't revert back our WimbootCompress.ini file.

 

I think it's easy to replicate the issue scenario, just creating a second set of boot files/folders into NTFS partition in a copy of some of our 2 partitions (FAT-32 + NTFS) VHDs. (I have none by the way, all I have are single NTFS partition).

 

NOTE: It seems to me it is better to check this on a UEFI PC that does not have x64 drivers in the UEFI firmware.

 

I have a PC with that characteristics, but it's not in use right now, just give me some time and I will check this and report back.

 

I assume we have a very high possibility to get rid for ever of listing those files in [Exclusion List] section.

 

alacran

[antonino61]

well, in the end, I cannot help but enthuse at alacrán's having proved to us all that el ser es y el noser noés --> u cannot delete the non-existent. 

very close to this topic, though, I remember Miguel de Unamuno once wondering: Si yo tengo que agarrar el tranvía para ir al teatro, ?cuál es más importante? ?el tranvía o el teatro? (If I have to catch a trolley to go to the theatre, which is more important? the trolley or the theatre?)

[wimb]

WIM File Captured Not with VHD_WIMBOOT can contain bootmgr and Boot and EFI folder.

 

For the case that such file is used in VHD_WIMBOOT in APPLY Mode then it is good that these items are in the [PrepopulateList] Section

 

For the case of CAPTURE with VHD_WIMBOOT you don't want to Capture bootmgr and Boot and EFI folder.

 

So it is good to have these items in the [ExclusionList] Section of WimBootCompress.ini

 

So in order to cover all cases it is good to keep WimBootCompress.ini as it is now, which  gives good protection against Boot Failure

[antonino61]

so, if I have understood correctly, after applying the wim into the vhd, we might as well do a 

bcdboot c:\windows /s c:

and have it that way.

[alacran]

I just ran a test on a UEFI machine that lacks x64 UEFI drivers in its firmware.

Used same WIM file I had, to make a new LZX compact mode installation into a 2 GB VHD, created by VHD_WIMBOOT having 2 partitions, keeping it mounted, also attached my previous single NTFS partition VHD and copied BOOT and EFI folders + bootmgr and BOOTNXT files to the NTFS partition of new W10x64_MX_LZX_1.vhd, and added with BootIce a fake New Win 7/8 entry to MBR and UEFI BCDs of FAT-32 partition (to use as markers) of W10x64_MX_LZX_1.vhd, and detached the VHDs.

Copied W10x64_MX_LZX_1.vhd to my bootable USB 3.0 device, and manually added it to both grub4dos menu.lst

 

It booted very fine in UEFI environment as Ramdisk, opened BCD of current system with BootIce and certanly this BCD was the one located into FAT-32 partition with a fake New Win 7/8 entry.

 

I know this issue was not present in MBR version, but just in case l also booted in another PC in MBR environment as Ramdisk, opened BCD of current system with BootIce and certanly this BCD was the one located into FAT-32 partition with a fake New Win 7/8 entry.

 

So it seems this proves the old G4E issue is not present anymore, and (if desired) we could get rid of listing those files in [Exclusion List] section.

 

Please see attached photos.

 

Well, once I proved my point beyond any doubt, I have to admit that personally I really don't care very much about having those files listed into both sections.

 

But now the author of the program (if he wants) could re-evaluate what to do, having all the info updated and available.

 

alacran

Attached Thumbnails

• 
• 

[antonino61]

me, of course, I tested it in legacy mode and I only have the efi line, obviously, so I can confirm alacrán's idea, as well as I can confirm that it is, albeit paradoxically, better to (re-)apply the wim with winntsetup, as I said a couple of posts earlier.

[alacran]

wimb, on 04 Feb 2022 - 09:09 AM, said:

WIM File Captured Not with VHD_WIMBOOT can contain bootmgr and Boot and EFI folder.

For the case that such file is used in VHD_WIMBOOT in APPLY Mode then it is good that these items are in the [PrepopulateList] Section

No, this doesn't work in that way.

JFYI:

 

Once the WIM file is created by another tool, if we apply it using VHD_WIMBOOT, it doesn't matter what says the WimbootCompress.ini file into our VHD_WIMBOOT program.

In fact, it is not used during apply, the only WimbootCompress.ini file used during apply is the one located in \Windows\System32\WimbootCompress.ini INTO the WIM image file.

The WimbootCompress.ini file is usually easily replaced during Capture for VHD_WIMBOOT.

 

In an already captured WIM file, we need to first update the WIM file to replace that file by means of wimlib-imagex or wimlib-clc, in a separate procedure, before apply the WIM file, as I did to replace it with my proposed version of WimbootCompress.ini file, before the next apply process when running my tests.

 

Please see attached pictures.

 

alacran

Attached Thumbnails

• 
• 

[wimb]

 

So it seems this proves the old G4E issue is not present anymore, and (if desired) we could get rid of listing those files in [Exclusion List] section.

 

Well, once I proved my point beyond any doubt, I have to admit that personally I really don't care very much about having those files listed into both sections.

 

But now the author of the program (if he wants) could re-evaluate what to do, having all the info updated and available.

 

 

Nice test and it proves your statement that a 2-partition VHD is booting fine while having additional Boot and EFI folder on second partition

 

 

No, this doesn't work in that way.

JFYI:

 

Once the WIM file is created by another tool, if we apply it using VHD_WIMBOOT, it doesn't matter what says the WimbootCompress.ini file into our VHD_WIMBOOT program.

In fact, it is not used during apply, the only WimbootCompress.ini file used during apply is the one located in \Windows\System32\WimbootCompress.ini INTO the WIM image file.

The WimbootCompress.ini file is usually easily replaced during Capture for VHD_WIMBOOT.

 

You are quite right. The WimBootCompress.ini file located in VHD_WIMBOOT is Not used during APPLY.

It is the WimBootCompress.ini file located in Windows\System32 folder of WIM file that is effective during Apply.

 

Nevertheless I think I keep the entries for wofadk.sys and bootmgr and Boot and EFI folder in the WBC Mini file.

These extra entries don't hurt for the UsedSize and in any case reminds us of the need to have these files / folders Uncompressed.

 

You have Not proven that Capture with WBC Mini Setting using your WBC file and Apply in Compact LZX mode for the case of Windows 7 is Booting succesfull.

It will Not be since in that case wofadk.sys file could be LZX Compressed.

[alacran]

 

You are quite right. The WimBootCompress.ini file located in VHD_WIMBOOT is Not used during APPLY.

It is the WimBootCompress.ini file located in Windows\System32 folder of WIM file that is effective during Apply.

 

1 - Nevertheless I think I keep the entries for wofadk.sys and bootmgr and Boot and EFI folder in the WBC Mini file.

These extra entries don't hurt for the UsedSize and in any case reminds us of the need to have these files / folders Uncompressed.

 

2 - You have Not proven that Capture with WBC Mini Setting using your WBC file and Apply in Compact LZX mode for the case of Windows 7 is Booting succesfull.

It will Not be since in that case wofadk.sys file could be LZX Compressed.

 

1 - As I said on this post:

 

So it seems this proves the old G4E issue is not present anymore, and (if desired) we could get rid of listing those files in [Exclusion List] section.

 

Please see attached photos.

 

Well, once I proved my point beyond any doubt, I have to admit that personally I really don't care very much about having those files listed into both sections.

 

 

I was more interested in proving the old issue is not present anymore in G4E, and I'm agree having those files listed in both sections does not hurt in any way, also you are the author of the program and you take the decisions and I have always respected that.

 

2 - I never suggested to use it for 7 or 8.x OSs, I commented the wofadk.sys driver that WinNTSetup installs in those OSs to let them be installed in Compact mode or Wimboot mode is an old version 10.0.14393.0 from 16-July-2016, that is not suitable to use the proposed version of WimbootCompress.ini, then as the proposed WimbootCompress.ini file was not intended to be used in 7 or 8.x, I didn't include wofadk.sys under [PrepopulateList].

 

Thats why I added this line:

 

; Version for Mini-10-2004.vhd(s) by alacran

 

alacran

Attached Thumbnails

• 

[wimb]

1 - As I said on this post:

 

I was more interested in proving the old issue is not present anymore in G4E, and I'm agree having those files listed in both sections does not hurt in any way, also you are the author of the program and you take the decisions and I have always respected that.

 

 

Good to know the old issue is not present anymore in G4E    and good that keeping the WimBootCompress.ini files as they are is OK for you 

 

It is a convenient solution that we can select now simply what version of WimBootCompress.ini file is integrated in the Captured WIM file.

[alacran]

Just something I forgot to mention that seems relevant for the record:

 

By the way during testing in another machine, the G4E issue is not present anymore, was additionally proved the portability, as having the drivers LZX compacted, the 10 2004 LZX VHD Rambooted very fine from a USB device in that machine too.

 

alacran

[alacran]

Mitigate the grow up of used space into Mini-10x64-LZX.vhd after a filedisk boot:

 

During my tests I collected the following info:

 

Using WOF_Compress program to make the list of files compression status (before and after first boot), and Notepad++ (Compare plugin), I was able to find the files that are modified/edited and also created during first boot.

 

NOTES:

1. Mini-10x64-LZX.vhd was booted as filedisk and closed using Clean + Shutdown TI, to clean all the known *.log and *.etl files.
2. No other task was done during this test.
3. XXX is the user name, edit as required.

 

Ex-Compressed files that are not compressed anymore:

Spoiler

 

\ProgramData\Microsoft\Windows\AppRepository\StateRepository-Deployment.srd
\ProgramData\Microsoft\Windows\AppRepository\StateRepository-Deployment.srd-shm
\ProgramData\Microsoft\Windows\AppRepository\StateRepository-Machine.srd
\ProgramData\Microsoft\Windows\AppRepository\StateRepository-Machine.srd-shm
\ProgramData\Microsoft\Windows\DeviceMetadataCache\dmrc.idx
\Users\XXX\AppData\Local\ConnectedDevicesPlatform\CDPGlobalSettings.cdp
\Users\XXX\AppData\Local\ConnectedDevicesPlatform\L.XXX\ActivitiesCache.db
\Users\XXX\AppData\Local\ConnectedDevicesPlatform\L.XXX\ActivitiesCache.db-shm
\Users\XXX\AppData\Local\IconCache.db
\Users\XXX\AppData\Local\Microsoft\Windows\Caches\cversions.1.db
\Users\XXX\AppData\Local\Microsoft\Windows\Caches\cversions.3.db
\Users\XXX\AppData\Local\Microsoft\Windows\Caches\{AFBF9F1A-8EE8-4C77-AF34-C647E37CA0D9}.1.ver0x0000000000000009.db
\Users\XXX\AppData\Local\Microsoft\Windows\Explorer\iconcache_16.db
\Users\XXX\AppData\Local\Microsoft\Windows\Explorer\iconcache_256.db
\Users\XXX\AppData\Local\Microsoft\Windows\Explorer\iconcache_32.db
\Users\XXX\AppData\Local\Microsoft\Windows\Explorer\iconcache_48.db
\Users\XXX\AppData\Local\Microsoft\Windows\Explorer\iconcache_idx.db
\Users\XXX\AppData\Local\Microsoft\Windows\Explorer\thumbcache_16.db
\Users\XXX\AppData\Local\Microsoft\Windows\Explorer\thumbcache_256.db
\Users\XXX\AppData\Local\Microsoft\Windows\Explorer\thumbcache_48.db
\Users\XXX\AppData\Local\Microsoft\Windows\Explorer\thumbcache_idx.db
\Users\XXX\AppData\Local\Microsoft\Windows\Notifications\wpndatabase.db
\Users\XXX\AppData\Local\Microsoft\Windows\Notifications\wpndatabase.db-shm
\Users\XXX\AppData\Local\Microsoft\Windows\UsrClass.dat
\Users\XXX\AppData\Local\Microsoft\Windows\UsrClass.dat.LOG1
\Users\XXX\AppData\Local\Microsoft\Windows\UsrClass.dat{4e65ecf4-7da4-11ec-b461-f44d309f40c1}.TM.blf
\Users\XXX\AppData\Local\Microsoft\Windows\UsrClass.dat{4e65ecf4-7da4-11ec-b461-f44d309f40c1}.TMContainer00000000000000000001.regtrans-ms
\Users\XXX\AppData\Local\Microsoft\Windows\UsrClass.dat{4e65ecf4-7da4-11ec-b461-f44d309f40c1}.TMContainer00000000000000000002.regtrans-ms
\Users\XXX\AppData\Local\Packages\Microsoft.Windows.StartMenuExperienceHost_cw5n1h2txyewy\Settings\settings.dat
\Users\XXX\AppData\Local\Packages\Microsoft.Windows.StartMenuExperienceHost_cw5n1h2txyewy\Settings\settings.dat.LOG1
\Users\XXX\AppData\Local\Packages\Microsoft.Windows.StartMenuExperienceHost_cw5n1h2txyewy\Settings\settings.dat.LOG2
\Users\XXX\AppData\Local\Packages\Microsoft.Windows.StartMenuExperienceHost_cw5n1h2txyewy\TempState\TileCache_100_0_Data.bin
\Users\XXX\AppData\Local\Packages\Microsoft.Windows.StartMenuExperienceHost_cw5n1h2txyewy\TempState\TileCache_100_0_Header.bin
\Users\XXX\NTUSER.DAT
\Windows\ServiceProfiles\LocalService\AppData\Local\FontCache\FontCache-FontFace.dat
\Windows\ServiceProfiles\LocalService\AppData\Local\FontCache\FontCache-S-1-5-18.dat
\Windows\ServiceProfiles\LocalService\AppData\Local\FontCache\FontCache-S-1-5-21-3494572828-4219223507-4262021320-1000.dat
\Windows\ServiceProfiles\LocalService\AppData\Local\FontCache\FontCache-System.dat
\Windows\ServiceProfiles\LocalService\NTUSER.DAT
\Windows\ServiceProfiles\NetworkService\NTUSER.DAT
\Windows\System32\config\BBI
\Windows\System32\config\DEFAULT
\Windows\System32\config\DRIVERS
\Windows\System32\config\SAM
\Windows\System32\config\SECURITY
\Windows\System32\config\software
\Windows\System32\config\TxR\{53b39e3e-18c4-11ea-a811-000d3aa4692b}.TM.blf
\Windows\System32\config\TxR\{53b39e3e-18c4-11ea-a811-000d3aa4692b}.TMContainer00000000000000000001.regtrans-ms
\Windows\System32\config\TxR\{53b39e3e-18c4-11ea-a811-000d3aa4692b}.TMContainer00000000000000000002.regtrans-ms
\Windows\System32\spp\store\2.0\cache\cache.dat
\Windows\System32\wbem\Repository\INDEX.BTR
\Windows\System32\wbem\Repository\MAPPING1.MAP
\Windows\System32\wbem\Repository\MAPPING2.MAP
\Windows\System32\wbem\Repository\MAPPING3.MAP
\Windows\System32\wbem\Repository\OBJECTS.DATA
 

 

New files created:

Spoiler

 

\Users\XXX\AppData\Local\Microsoft\Windows\Caches\{AFBF9F1A-8EE8-4C77-AF34-C647E37CA0D9}.1.ver0x000000000000000b.db
\Users\XXX\ntuser.dat.LOG1
\Users\XXX\ntuser.dat.LOG2
\Users\XXX\NTUSER.DAT{4e65ebb8-7da4-11ec-b461-f44d309f40c1}.TM.blf
\Users\XXX\NTUSER.DAT{4e65ebb8-7da4-11ec-b461-f44d309f40c1}.TMContainer00000000000000000001.regtrans-ms
\Users\XXX\NTUSER.DAT{4e65ebb8-7da4-11ec-b461-f44d309f40c1}.TMContainer00000000000000000002.regtrans-ms
\Windows\debug\PASSWD.LOG  >>> This can be omited as it is created every boot (as a zero bytes file in my case as I don't use password)
\Windows\ServiceProfiles\LocalService\NTUSER.DAT.LOG1
\Windows\ServiceProfiles\LocalService\NTUSER.DAT.LOG2
\Windows\ServiceProfiles\LocalService\NTUSER.DAT{5fadf27b-7da2-11ec-b460-d8310a53e746}.TM.blf
\Windows\ServiceProfiles\LocalService\NTUSER.DAT{5fadf27b-7da2-11ec-b460-d8310a53e746}.TMContainer00000000000000000001.regtrans-ms
\Windows\ServiceProfiles\LocalService\NTUSER.DAT{5fadf27b-7da2-11ec-b460-d8310a53e746}.TMContainer00000000000000000002.regtrans-ms
\Windows\ServiceProfiles\NetworkService\NTUSER.DAT.LOG1
\Windows\ServiceProfiles\NetworkService\NTUSER.DAT.LOG2
\Windows\ServiceProfiles\NetworkService\NTUSER.DAT{53b39e88-18c4-11ea-a811-000d3aa4692b}.TM.blf
\Windows\ServiceProfiles\NetworkService\NTUSER.DAT{53b39e88-18c4-11ea-a811-000d3aa4692b}.TMContainer00000000000000000001.regtrans-ms
\Windows\ServiceProfiles\NetworkService\NTUSER.DAT{53b39e88-18c4-11ea-a811-000d3aa4692b}.TMContainer00000000000000000002.regtrans-ms
\Windows\System32\config\BBI.LOG1
\Windows\System32\config\BBI.LOG2
\Windows\System32\config\DEFAULT.LOG1
\Windows\System32\config\DEFAULT.LOG2
\Windows\System32\config\DRIVERS.LOG1
\Windows\System32\config\DRIVERS.LOG2
\Windows\System32\config\DRIVERS{53b39e70-18c4-11ea-a811-000d3aa4692b}.TM.blf
\Windows\System32\config\DRIVERS{53b39e70-18c4-11ea-a811-000d3aa4692b}.TMContainer00000000000000000001.regtrans-ms
\Windows\System32\config\DRIVERS{53b39e70-18c4-11ea-a811-000d3aa4692b}.TMContainer00000000000000000002.regtrans-ms
\Windows\System32\config\SAM.LOG1
\Windows\System32\config\SAM.LOG2
\Windows\System32\config\SECURITY.LOG1
\Windows\System32\config\SECURITY.LOG2
\Windows\System32\config\SOFTWARE.LOG1
\Windows\System32\config\SOFTWARE.LOG2
 

 

For your convenience both files are attached in Files change in Mini-10x64-LZX.7z Password = alacran

 

At first seen we can notice:

1. Not a single *.sys driver was uncompressed.
2. Many new files are created into \Windows\ServiceProfiles\ folder.
3. Many new files are created into \Windows\System32\config\ folder (Registry location).

The info in previous lists helped me to mitigate the grow up of used space into Mini-10x64-LZX.vhd after a filedisk boot, without the need to rebuild it or use an spare copy of it. So I made the following:

1. Added all the lines into New Files.txt to \Win_Reduce_Trusted-61\Win_Reduce\File_List\Custom_remove_files.txt and ran offline VHD_WIMBOOT_Trusted.cmd and selected only Custom Filelist.
2. Edited the \WOF_Compress\makebt\WimBootReCompress.ini [PrepopulateList] to be the same as in the new WimbootCompress.ini (but previously kept a copy of original file) and ran offline WOF_Compress_Trusted.cmd

This brought back the used space as it was before first boot.

 

NOTE-2: Depending of the tasks made during your filedisk boot, additional files can be created or edited.

 

alacran

Attached Files

•  Files change in Mini-10x64-LZX.7z   1.33KB   1351 downloads