alacran
Content Type
Profiles
Forums
Events
Posts posted by alacran
-
-
JFYI
After making several failled intents to Ramboot Differential VHDs by means of grub4dos for UEFI, this is the answer got from yaya to the issue report made in GitHub page of grub4dos:
Issue: https://github.com/chenall/grub4dos/issues/379
Answer: https://github.com/chenall/grub4dos/issues/379#issuecomment-1258001726
QuoteG4E once realized the first level difference, but it has no practical use, just an experiment. This function has been removed in the new version. No longer supported!
Differential VHDs are not directly supported anymore in G4E. So no way to Ramboot them.
Only option remaining in grub4dos to filedisk boot differential VHDs (in MBR and UEFI), is by means of using the external command ntloader.
alacran
0 -
You don't need to read all the 9 pages of that topic mentioned by our friend Jaclaz.
Read this 3 posts, all info you require is there:
Building your MinWin:
http://reboot.pro/index.php?showtopic=22621&page=8#entry221675
http://reboot.pro/index.php?showtopic=22621&page=8#entry221680
Testing Differential VHDs made from MinWin installations:
http://reboot.pro/index.php?showtopic=22195&page=2#entry221689
alacran
1 -
JFYI
Grub4dos UEFI version support of differential VHDs is available since v 2021-01-31:
Quote2021-01-31 (yaya)
Supports starting a first-level differential VHD image.alacran
0 -
I think following info could be useful for some readers of this topic:
In a previous post I shared my MinWin_Medium_Profile_2022-08-20
That includes the option to enable automatically attach a VHD to Y drive every boot, this option works fine in all scenarios, even if booting from USB, or a WinPE were all drive letters have changed.
This can be used in MinWin or any other mode installations. To include this option in an allready intalled OS, you can find the info and Download here: VHD to fixed drive v1.2
But for people having a good amount of Ram available, it is also possible to load your favorite VHD(s) to Ram automatically every boot, in all previously mentioned scenarios, just by editing a little CMD file, changing the VHD name and drive letter, or adding new line(s) to Ram load additional VHD(s), always keeping in mind that the VHD(s) fit in the available Ram and there is still enought Ram available for the OS, the booting time may have certaing small delate depending of the amount of GB that we will load to Ram.
Load_RamDisk v1.0 (2022-08-30)
This can be used in MinWin or any other mode installations, just by following the instructions in the README file, in case you want to disable (but keep available) any previous service to automatically attach a VHD, you can use:
ServiWin by nirsoft, just select Services and find the service name in the list and by a right click on it select Change Startup Type and select disabled.
EDIT: Forgot to mention Load_RamDisk is also possible to attach/mount as file disk, NOT as Ramdisk a VHD or IMG file jus by editing the CMD file, instructions inside the new CMD file.
Hope this can be useful for some of you
alacran
0 -
Hi, JFX
In MBR environment there is no problem with dynamic VHDs, and yes in fact they load faster than fixed size VHDs.
But in UEFI the problem is not in SVBus driver, who does not support Rambooting dynamic VHDs is grub4dos for UEFI, at least untill last time I checked in the chinese forum where is located its page: http://bbs.c3.wuyou.net/forum.php?mod=viewthread&tid=422652
I read some months ago in a Post from Yaya (who started developing the UEFI version) on that page that the support for differencing VHDs was developed and working fine in the last version at that time. but I never have being interested in this kind or VHDs and didn't pair very much attention to this. By the way I never have tested this feature.
EDIT: 2021-01-31 (yaya) Supports starting a first-level differential VHD image.
About the WUB, yes it can be removed, it is there doing nothing.
About native VHD ramdisk booting from bootmgr.efi, well all WinPE WIM files are Ramboot capables, I ram some tests with no luck, back in August or September 2020, trying to boot a OS drive captured in a single index WIM file, applying the bootable flag, and using the external file boot.sdi but a PE also makes use of the internal driver: \Windows\System32\drivers\fbwf.sys, (file-based wright filter driver) not present in the OS version, also found many things in the Registry that are very different.
EDIT: I edited my previous post about the Medium profile, it is now MinWin_Medium_Profile_2022-08-20
Changes:
New "Optional PStart pre-configured" folder.
Medium\Add\Port_Apps\WUB folder was deleted.
Medium\Add\Program Files\VHD_Loader folder: Now includes delete REG files.
alacran
0 -
I will share with all of you my MinWin Medium Profile.
EDIT: It is now MinWin_Medium_Profile_2022-08-20
Hope you like it.
See you later fellows.
alacran
0 -
Quote
@alacran WinNTSetup will load software hive, so you loose ~ 60 MB (hmm, I should re-compress it afterwards),
rest up to you to be find...When I capture a drive using wimlib, I usually use a modded WinbootCompress.ini, and the WinbootCompress.ini used is automatically copied into \Windows\System32, then the WIM is ready for applying it using wimlib with this new WinbootCompress.ini
Please take the following as a kind suggestion, but of course as you are the author of the program, the decision is yours:
With all due respect to you my friend, IMHO I think it may be easier if you could use a set of WinbootCompress.ini files, and depending of the OS version use the respective file, and just let wimlib apply the selected WIM index IAW the respective file used, and avoid extra decompression that induce file fragmentation or recompression that induce free space fragmentation, I don't have any experiece with Win11 but it seems it may need its own WinbootCompress.ini file.
Following is useful to avoid high fragmentation in my Wimboot:WIMCOPY mode look alike installations:
To avoid the fragmentation in small (upto 2 GB or 3 GB depending of the compression used) fixed size VHDs, as I use to have the NTFS partition as second partition, it is made first of only 50 MB, and once formated it's expanded to the full space, then in case of making a (1400 MB) VHD similar to Wimboot:WIMCOPY mode from a re-captured MinWin, I copy first the WIM file to the root of the NTFS and then create a Wimboot folder and move the WIM into it, and the resulting installation using wimlib is 0% fragmented, but if the Wimboot folder is created first the trick doesn't work.
UPDATE: Today I tested this other option that also works fine: if the Wimboot folder is created outside of the VHD and the WIM file is copied/moved into this folder, and then the folder and its content is copied into the VHD, there is also 0% fragmentation after installation.
By the way only fixed size VHDs are capable to Ramboot by means of grub4dos for UEFI + SVBus driver, unless there is new info I'm not aware.
Also I want to share here this, that may be interesting for MinWin builds: http://reboot.pro/index.php?showtopic=22650
See you latter my friend.
alacran
0 -
On 8/10/2022 at 1:48 PM, JFX said:
Normally Windows 10 systems above build 17000 don't need any WOF exclusion.
But there were some reports that it don't work for some people (maybe hardware related).
None of them told if they used BIOS or UEFI booting. This also makes a difference!
EFI bootmgr has reading support for compressed files, BIOS bootmgr has not.You can set SkipBuildsAbove17000 in Tools\Compact\WimBootCompress.ini if you sure you don't have
this problem with your machines.At least since Win 10 v2004 (20H1), I can confirm without any doubt the Bios bootmgr has reading support for compressed files, just exactly the same EFI bootmgr has.
I always test all my builds in Bios and in UEFI environments.
Thats why I'm using same [PrepopulateList] as in the WimmootCompress.ini contained in this version, just adding following two lines:
\Windows\System32\pwdrvio.sys
\Windows\System32\pwdspio.sysI found since this version all *.sys drivers. don't need to be uncompressed as before, including SVBus driver that is loaded during the very first stages of boot process, this is valid for Bios and UEFI
So even applying SkipBuildsAbove17000=1, in a Wimboot mode installation, of a re-captured WIM file from a MinWin VHD, (based in 10 2004), having all my programs, made using WinNTSetup, used space is very much bigger than using wimlib directly, that follows to the letter the WimbootCompress.ini contained in the WIM file.
Also tried using additionally my same [PrepopulateList] section, in your version in \WinNTSetup_v526\Tools\Compact\WimBootCompress.ini, and the resulting used space is still bigger.
The used space, (just after installation) I got when making a Wimboot mode installation of a MinWin based in 10 2004, using wimlib-imagex or Wimlib-clc is never bigger than 60 MB, usually it is 58.9 MB, then it fits fantastic in a 512 MB 2 partition VHD. Very usefull to Ramboot in a PC having only 2 GB of Ram.
P.D. : New traslation is pending, I'm running some test about something else, but I'll do it ASAP.
alacran
0 -
JFYI
I can confirm WinNTSetup v5.2.6 is now capable to install a WIM file captured from a MinWin VHD.
I tested this applying the image using WinNTSetup in Wimboot mode to a 2 partitions 512 MB VHD:
Comparative wih same image applied using wimlib to a similar VHD:
MinWin-WB-Fix.vhd >>> 512 MB Wimboot, made with WinNTSetup VHD, used space in NTFS partition is 315.5 MB, 32% fragmented.
MinWin-WB.vhd >>> 512 MB Wimboot, VHD made with wimlib v1.13.5, used space in NTFS partition is 58.4 MB, 0% fragmented.As you can see the resulting used space into the VHD NTFS partition is 5.4 X the used space compare with the used space if applying the image using Wimlib-clc or directly wimlib-imagex, also the VHD applied using WinNTSetup is highly fragmented 32%, when the other is 0% fragmented.
As WinNTSetup used same wimlib v1.13.5, and the WimbootCompress.ini file is the same in both cases, all this increase in size, caused by 2034 full size (real) files, (that are pointers when not using WinNTSetup), is caused for an additional process that decompressed this files and making them real files, that is coded into WinNTSetup, and should no apply to at least Windows 10 2004 (20H1) and newer (haven't tested before this), maybe is not a bad idea to verify the WimbootCompress.ini into 2019 versions just to confirm (but I don't have them).
For more detailed info please see my post in reboot.pro: http://reboot.pro/index.php?showtopic=22621&page=7#entry221576
Mentioned post also include photos and:
Full size files.7z >>> Password = alacran That are pointers when not using WinNTSetup, and using wimlib v1.13.5 directly.
WimBootCompress_for_WIMCOPY_.7z >>> Password = alacran My modded WimBootCompress.ini v2022-08-10 into the WIM file applied, NOTE: It is there since a previous test,
alacran
0 -
I made a post and added to it a download link to my MediaFire free account for:
Spanish_translation.7z Password: alacran
This is based in v5.25
Please excuse me for the long time since previous version.
And it disapeared, so I'm posting it again.
alacran
1 -
@ JFX
Currently ONLY partition layout available in WinNTSetup to make a 2 partitions MBR initialized VHD, bootable in Bios/UEFI environments is having the FAT-32 Active Primary Partition as second partition.
Could you consider adding in a future version the option to make a 2 partitions MBR initialized VHD, bootable in Bios/UEFI environments having the FAT-32 Active Primary Partition as first partition?
I have being dealing with this using a pre-made VHD, and the boot files/folders are created fine if the FAT-32 is the first partition, but I'm thinking in make the life easier for non-advanced users, or some people that are partially visually impaired as our fellow devdevadev.
alacran
1 -
I jut tested SVBus_v1.3 signed, and it is working fantastic.
It allowed me to filedisk boot and Ramboot without the need to edit all BCD files.
QuoteNew SVBus_v1.3 signed was just uploaded.
v1.3 uses a different certificate that is not blacklisted so far, so there is no need to edit all the internal and external BCDs
Download link to reboot.pro forum Downloads Section: http://reboot.pro/index.php?app=downloads&showfile=625
My thanks to JFX who shared with me the link to github page.
But the download lacks following files:
Install_SVBus.txt
instx64.exe
instx86.exe
So for users convenience I included them into this package. A README file with instructions is also included in this package.alacran
Download link to reboot.pro forum Downloads Section: http://reboot.pro/index.php?app=downloads&showfile=625
alacran
0 -
40 minutes ago, JFX said:
No, --recover-data ignores data corruption. That's not something that should be simply ignored.
Wimlib has an error output. Don't know why I have not add this. Will be available in next version.BTW: DISABLE_INTEGRITY_CHECKS is useless in BCD loadoptions.
About; --recover-data ignores data corruption.
Yes, you are right, I am aware that is the info mentioned in wimapply.pdf.
But I also remember in a post on wimlib forum Synchronicity (Eric Biggers) mentioned that it is the usual way Dism works when applying a WIM file.
about: DISABLE_INTEGRITY_CHECKS is useless in BCD loadoptions.
That's not fully right.
It is still usefull upto 10 v2004 (20H1), that's why I still prefer to use this version to make my Rambootable Mini VHDs (having SVBus driver installed).
It doesn't work anymore starting in 20H2, for 20H2 and newer we can pre-load (by means of grub2 or grub4dos for UEFI) EfiGuardDxe.efi before running the commands to Ramboot the VHD to solve this.
alacran
0 -
Hi my friend.
I found an issue in v5.25, from my post: http://reboot.pro/index.php?showtopic=22621&page=6#entry221512
QuoteTried to install into the VHD, (NTFS partition), my MinWin-10x64.wim in Wimboot mode using WinNTSetup, it failed to install several times, and always gave me a message saying that wimlib_extact_image 0xF2: Failed to open a file, please see attached photo (it is pending to find the cause of this failure yet).
Then used wimlib-clc program by Tokener to install MinWin-10x64.wim into the NTFS partition on the VHD in Wimboot mode, all was made perfectly fine.
For the complete info please read the full linked post.
Additional info that can be useful for you:
wimlib-clc has pre-set the parameter --recover-data in apply Tab.
Perhaps you are not using in WinNTSetup the parameter --recover-data in wimlib during apply.
--recover-data parameter emulates the way Dism works during apply.
And as a MinWin VHD had many cuts (per design), it is very possible the main source of the issue, and using the parameter --recover-data could help solve the issue (in case you are not usig it).
alacran
0 -
JFYI
From my post: http://reboot.pro/index.php?showtopic=22621&page=6#entry221511
QuoteFor readers convenience I attached here:
Modded_SySWoW_2022-08-01.7z Password = alacran
Where !\Windows\SysWOW64\mshtml.dll line is now commented to save in our MinWin VHD 17.2 MB (uncompressed) or 7.34 MB (if Compact LZX compressed).
If you need to read HTML (*.chm) help files into 32 bits programs, just uncomment the line.
alacran
Modded_SySWoW_2022-08-01.7z 2.89KB
alacran
0 -
Just finished testing all features available in the MinWin version created with WinNTSetup v5.25, all useful things are available and open fine, including Event Viewer, Task Manager, Services Management, MS Config, PowerShell, etc.
And all ornamentary and superfluous things including the (CR)Apps are removed.
Congratulations my friend you did a fantastic work.
Only thing I don't like of MinWin is during first boot after installation it takes a very long time to arrive to the desktop. And during long periods it doesn't seem to be doing anything as the HD led is not flashing, but if pressing the Caps Lock or Num Lock Keys they work fine, so we can confirm it is not blocked so It is better to be very pacient, but I would like to know what the hell is the PC doing all this time when the HD led is not flashing.
By the way the lines added into Modded_SySWoW (2022-07-30) can be edited by commenting or deleting !\Windows\SysWOW64\mshtml.dll to squeeze a few more MB, (17.2 MB uncompressed, 7.34 MB if Compact LZX compressed).
Without losing the capability to run LibreOfficePortable and lz4_compressor, but doing it we lose the capability to read the HTML (.chm) help files into 32 bits programs.
alacran
0 -
7 hours ago, JFX said:
Yeah, I guess this is the problem. You change the system disk to be a RAMDisk,
Windows reacts like this is a full hardware change and will need same SysWoW64 files to be signed.You can edit Tools\CATTrim.ini and add the lines:
..\SysWOW64\basesrv.dll ..\SysWOW64\bcryptprimitives.dll ..\SysWOW64\csrsrv.dll ..\SysWOW64\ntdll.dll ..\SysWOW64\kernel32.dll ..\SysWOW64\kernelbase.dll ..\SysWOW64\gdi32.dll ..\SysWOW64\gdi32full.dll ..\SysWOW64\ucrtbase.dll ..\SysWOW64\winsrv.dll ..\SysWOW64\win32u.dll ..\SysWOW64\normaliz.dll ..\SysWOW64\advapi32.dll ..\SysWOW64\bcryptprimitives.dll ..\SysWOW64\cfgmgr32.dll ..\SysWOW64\clbcatq.dll ..\SysWOW64\combase.dll ..\SysWOW64\comctl32.dll ..\SysWOW64\coml2.dll ..\SysWOW64\crypt32.dll ..\SysWOW64\cryptbase.dllBTW: there is a newer SVBUS available.
Hi JFX
Thanks for the link to svbus_1.3, just downloaded it, but haven't tested it yet.
I can confirm adding this lines to Tools\CATTrim.ini solves the issue. Now my MinWin with SVBus installed is capable of filedisk boot and Ramboot again if using CATTrim.
But I noticed after apply it, several additional *.log files (that never existed before) are created in catroot2 after off-line apply CATTrim and reboot:
C:\Windows\System32\catroot2\edb00001.log
C:\Windows\System32\catroot2\edb00002.log
C:\Windows\System32\catroot2\edb00003.log
C:\Windows\System32\catroot2\edb00004.log
C:\Windows\System32\catroot2\edb00005.log
C:\Windows\System32\catroot2\edb00006.log
C:\Windows\System32\catroot2\edb.log
C:\Windows\System32\catroot2\edbtmp.logEach one is 2 MB (total 16 MB on first boot), so if filedisk booting all this garbage accumulates every boot, not when Rambooting as all this garbage is created on Ram every boot.
IMHO and with all due respect to you my friend, CATTrim command works fine, but it's not really useful to reduce the OS size and future growup, on the contrary it induces the accumulation of more garbage.
Of course as always it depends of user preferences to apply CATTrim to his/hers OS or not.
alacran
0 -
5 hours ago, JFX said:
Interesting, maybe Tools\CATTrim.ini is still missing some important file that needs to be signed.
I'll will take a look at some full windows installations. The current file list is only based on my Win10PE research.BTW: It should be run against a fully installed Windows,
cause during setup some SysWoW64 files are scanned and needs to be signed.Yes it was run against a fully tested VHD, having SvBus driver Version=04/28/2020,1.2.0.0, (signed by a chinese guy) using EVRootCA.reg, that was installed manually, (not by SVBus_INST_Trusted-20), and all its BCD entries have LoadOptionsString = DISABLE_INTEGRITY_CHECKS present, and the VHD was filedisk booting and Rambooting very fine before ran CatRoot trim tool.
alacran
0 -
JFYI
From my post: http://reboot.pro/index.php?showtopic=22621&page=6#entry221504
QuoteI made a new review of my lines added to SySWoW.txt and now they are only 91 lines (all repeated lines and all files in SySWoW folder that don't have a respective file with same name present also in System32 folder were removed).
After removing all files that are not in the list anymore LibreOfficePortable and lz4_compressor are still working fine.
Also (on-line) cleared all Event Viewer Logs just before reboot, (as I now do after filedisk booting a MinWin VHD), and ran again Win_Reduce_Trusted-62, re-capture and re-apply using VHD_WIMBOOT_Trusted-67, and I got a good reduction in sizes, compared to the sizes in post No. 122
MinWin-10x64-LZX.vhd Used size In NTFS partition is now 906 MB was 936 MB >>> reduction 30 MB
MinWin-10x64-WB.vhd Used size in NTFS partition is now 57.2 MB was 58.6 MB >>> reduction 1.4 MB (Gain doesn't seem very notorious as almost all reduced files are pointers and not real files).
MinWin-10x64.wim Size is now 812 MB was 840 MB >>> reduction 28 MBFor readers convenience I attached here following files:
Modded_SySWoW (2022-07-30).7z Password = alacran
Clear_Event_Viewer_Logs.7z Password = alacran
NOTE: I recommend to always run Clear_Event_Viewer_Logs.bat as admin just before shout down the MinWin OS when filedisk booting to remove all event logs, not required when Rambooting, or if the OS will be re-captured and re-applied as in WimBootCompress.ini [ExclusionList] this two lines take care of that:
\Windows\System32\winevt\Logs\*
\Windows\System32\winevt\TraceFormat\*JFYI - CCleaner has an option to clear all Event Viewer Logs, it still works fine in Win7 but it doesn't work anymore in Win10.
alacran
Modded_SySWoW (2022-07-30).7z 2.75KB Password = alacran
Clear_Event_Viewer_Logs.7z 625bytes Password = alacran
alacran
0 -
JFYI
From my post: http://reboot.pro/index.php?showtopic=22621&page=5#entry221498
QuoteJust made a new MinWin build using WinNTSetup 5.2.5
New build made with WinNTSetup 5.2.5 is working fine. Source ISO used was Win10x64 v2004 es-MX.
......
I only edited SySWoW.txt, adding 112 lines to be able to run LibreOfficePortable and lz4_compressor , this way all my 32 bits Portable Apps run fine in MinWin.
For more info please read all the quoted post.
Modded_SySWoW.7z Password: alacran
From my post: http://reboot.pro/index.php?showtopic=22621&page=5#entry221500
QuoteTesting CatRoot trim tool:
Running from MinWin-10x64-WB.vhd, and having mounted MinWin-10x64-LZX.vhd on drive K, from WinNTSetup_v525 folder, I opened an elevated command prompt and ran following command:
WinNTSetup_x64.exe CATTRIM "K:\Windows"
The command ran fine and it was able to delete 20.6 MB on MinWin-10x64-LZX.vhd, please see attached picture.
Rebooted from MinWin-10x64-LZX.vhd, but it didn't boot anymore, so for me CatRoot trim tool didn't work fine. tested Ramboot and Filedisk boot, and both ways it fails to boot.
So CatRoot trim tool didn't work fine on my MinWin LZX VHD build.
alacran
0 -
On 7/18/2022 at 11:54 AM, JFX said:
WinNTSetup 5.2.5
- updated ADK tools to version 22621.1
- disables DumpStack.log.tmp file creation
- disables network requirement for Windopws 11 (disconnected devices only)
- Logs are saved in \Windows\Log\WinNTSetup\%Date%_%Time%
- added NVRAM log
- added NVRAM tool: WinNTSetup_x64 NVRAM
- added CatRoot trimm tool: WinNTSetup_x64 CATTrimHi JFX, thanks for the new version.
I will appreciate a lot a brief explanation about how to use NVRAM tool and CatRoot trim tool.
After downloading the v5.25 from MediaFire and run it the first time to download required non-distributable files from MS, I was able to find \WinNTSetup\Tools\CATTrim.ini, but I can't find anything related to NVRAM in \WinNTSetup\Tools\ folder.
alacran
0 -
Just downloaded v4.0, I'll test it and comment back.
alacran
0 -
JFYI
Some comments that I think may be usefull:
Usually majority of ETL files in standard OS are located into \Windows\System32\winevt\Logs, this folder doesn't exits in MinWin, so we don't have to worry for it, but many LOG and ETL files are also created in several other locations.
In MinWin the LOG and ELT files created after first boot are 100+ MB, and even more acumulate every boot, for more detailed info and files list please see this post.
Back in 2020-11-09 I experimented replacing some of this folders, containing the unwanted files, with 0 bytes files to mitigate the creation of so many LOG and ELT files.
The trick worked fine, and I made an script to do this, latter Wonko sugessted a more elegant version of the script, and wimb added it to his Win_Reduce_Trusted program.
Anyway I made a new updated version of my CMD file, and tested running it as TI by means of PowerRun, just after making a MinWin istallation in a VHD still mounted in drive H, for more detailed info please see this post.
Safe-to-Replace.cmd
@echo off ; ; Following will delete some folders, to latter create a 0 bytes file with same name, ; to avoid the potential re-creation of the folder and this way send new ETL/LOG files to limbo, ; they will be deleted only if present ; rmdir "H:\ProgramData\Microsoft\Windows\wfp" /s /q rmdir "H:\ProgramData\USOShared\Logs" /s /q rmdir "H:\Windows\Logs" /s /q rmdir "H:\Windows\SoftwareDistribution" /s /q rmdir "H:\Windows\System32\SleepStudy" /s /q rmdir "H:\Windows\System32\WDI" /s /q rmdir "H:\ProgramData\Microsoft\Network\Downloader" /s /q rmdir "H:\Users\Default\AppData\Roaming\Microsoft\Windows\Recent" /s /q rmdir "H:\Users\Default\AppData\Local\Microsoft\Windows\WebCache" /s /q ; ; Following files will be created only if there in not a folder or file with same name ; fsutil file createnew "H:\ProgramData\Microsoft\Windows\wfp" 0 fsutil file createnew "H:\ProgramData\USOShared\Logs" 0 fsutil file createnew "H:\Windows\Logs" 0 fsutil file createnew "H:\Windows\SoftwareDistribution" 0 fsutil file createnew "H:\Windows\System32\SleepStudy" 0 fsutil file createnew "H:\Windows\System32\WDI" 0 fsutil file createnew "H:\ProgramData\Microsoft\Network\Downloader" 0 fsutil file createnew "H:\Users\Default\AppData\Roaming\Microsoft\Windows\Recent" 0 fsutil file createnew "H:\Users\Default\AppData\Local\Microsoft\Windows\WebCache" 0 ExitAll was successful except the two last lines in both sections.
The 0 bytes files were not created in:
H:\Users\Default\AppData\Roaming\Microsoft\Windows\Recent >>> the folder was still present.
H:\Users\Default\AppData\Local\Microsoft\Windows\WebCache >>> the folder didn't exists yet and the file also was not created.
Then manually deleted the folder and created the two 0 bytes files in both locations.
Rebooted, and all was fine.
Now since the very first boot avoided the creation of a lot of LOG and ETL files. During first boot now they only use 48.4 MB, not more than 100 MB as before, I deleted all the remaing from SwiftSearch TI, and also made from booted MinWin the following directory junction:
MKLINK /J C:\Windows\System32\Logfiles F:\VHD\Logfiles >>> DO NOT replace it by a 0 bytes folder.
During boot the OS writes info into \Windows\System32\LogFiles\WMI\RtBackup >>> Criticall for booting
But, I found an unexpected result, following additional 0 bytes files were created (after first boot) too:
\Windows\ServiceProfiles\NetworkService\AppData\Roaming\Microsoft\Windows\Recent
\Windows\ServiceProfiles\LocalService\AppData\Roaming\Microsoft\Windows\Recent
\Windows\ServiceProfiles\NetworkService\AppData\Local\Microsoft\Windows\WebCache
\Windows\ServiceProfiles\LocalService\AppData\Local\Microsoft\Windows\WebCacheSo far I haven't noticed any issue, and all seems to work fine.
Also I suggest to disable following services in MinWin:
Diagtrack, DPS and SysMain.
By the way I noticed some files that were deleted during MinWin installtion, were re-created after first boot:
\Windows\Installer\SourceHash* >>> was re-created.
\Windows\ServiceProfiles\LocalService\AppData\Local\FontCache-*.dat >>> all re-created.I made a new finding:
\Windows\System32\dxdiagn.dll >>> is listed for deletion, comment it to avoid deletion because dxdiag.exe (directx dignostic) that is not listed for deletion, will be present in our build, and will not work without dxdiagn.dll
alacran
0 -
On 3/11/2022 at 1:51 AM, JFX said:
Looks like a bug with MEGA, removing and creating a new link doesn't help.
Rename it to WinNTSetup_version_522.rar, and try again, maybe that can help.
alacran
0
WinNTSetup v5.3.4
in Install Windows from USB
Posted
Just to let all of you know reboot.pro is back on line again: http://reboot.pro/index.php?showtopic=22687
alacran