Sweet! Thank you! I also think there should be an option to: 1. Hide all VC++ Redist packages from "Programs and Features" list. Abbodi's VC++ Redist script package contains several CMD files. One of the CMD files is ARP.cmd..bat and it is used exlusively to hide VC++ Redist from installed program list. 2. Integrate NSudo with context menu and/or intergrate RunAsTI script 3. Ability to skip setup questions about privacy
The images are substantially different. Not sure what you want to achieve, but the winpe image can be used for recovery purposes yes, but you would likely need additional software packages. If you want to boot winpe instead of winre, you would need to test it by renaming the winpe image to winre.wim and copy it to the appropriate location. Never done that myself though.
Its a bit off-topic: What I want is to have Macrium Rescue (WinPE ISO or WinRE ISO) to be used as recovery partition (on internal SSD drive). I have Macrium Rescue WinPE ISO and WinRE ISO already, but I don't know how to install either of them as recovery partitions on internal SSD drives. I load Macrium Rescue from USB instead. I'd rather load them from internal drive and have Windows OS load Macrium Rescue environment in case Windows OS becomes unbootable. I like how Dell and some other OEM's customize recovery partitions with many options, but ultimately, I just want to be able to load Macrium Rescue from an internal partiton to restore OS image in case OS becomes unbootable. Maybe Macrium software package has settings to install its Rescue Media parts onto default Windows OS recovery partition, but I can't check because I load Macrium exclusively from USB drives. On-topic: - MSMG Toolkit can make WinRE.wim a removable component. Removing it manualy saves a bit of space and doesn't corrupt component store or file integrity. - Does MSMG Toolkit apply TPM support requirement verification and other tweaks to boot.wim as well as install.wim? I think boot.wim controls TPM support requirement verification and if not mounted, tweak doesn't apply.
Can anyone tell me what is the correct way to remove WinPE from a mounted image? What I did: - Source > Select Source from <DVD> Folder > 1 - Do you want to mount Windows Setup Boot Image? [Yes] - Do you want to mount Windows Recovery Image? [No] - I removed everything that was inside index 1 folder "...\Mount\Boot\1". - Apply & Save Changes to Source Images - Do you want to trim unselected Image editions? [Yes] - Do you want to cleanup Image folder? [Yes] - Target > Make a DVD ISO Image The problem is, ISO size barely changed 3.26 GB (before WinPE removal), 3.25 GB (after WinPE removal). I also checked system size after Windows installation and used space (8.01 GB) + all system files (11.9 GB) had identical size to system with retained WinPE. Is it supposed to be such a small difference? The total content size of "...\Mount\Boot\1" folder was ~1.5 GB, so why is there almost no difference? After removal of Windows Recovery Environment (Winre.wim) located in the "...\Mount\Install\1\Windows\System32\Recovery", ISO size is reduced by 400 MB and disk total capacity after system installation is increased by 509 MB. So what do I actually get by removing WinPE? Nothing?
@n3ro97 good point, because my last iso's of W10 LTSC 2021 x64 stay in ~3.31GB and 3.25GB (including WinRE too)
When I'm trying to remove components I have this error: Spoiler System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.IO.PathTooLong Exception: The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters. System.IO.PathHelper.GetFullPathName( at at System.IO.Path.LegacyNormalize Path(String path, Boolean fullCheck, Int32 maxPathLength, Boolean expandShortPaths) at System.IO.Path. NormalizePath(String path, Boolean fullCheck, Int32 maxPathLength, Boolean expandShortPaths) at System.IO.Path.GetFullPathInternal(String path) at System.IO.File.SetAttributes(String path, FileAttributes fileAttributes) at .(String, FileAttributes, ) at ..(String) at .(String, ) at ..(String) at .(String, ) at ..(String) at .(String, ) at ..(String, String) at .(String, String, ) at..(String, String) at .(String, String, ) at..(String, String) at .(String, String, ) at ..Main(String[] args) --- End of inner exception stack trace --- at System.RuntimeMethodHandle.InvokeMethod(Object target, Object] arguments, Signature sig, Boolean constructor) at System.Reflection.RuntimeMethodInfo.Unsafelnvokelnternal(Object obj, Object] parameters, Object[] arguments) at System.Reflection.RuntimeMethodInfo.invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object] parameters, Cultureinfo culture) at_0 I have .NET Framework 4.7.2 installed and I'm running start.cmd on Windows 10 Pro Version 10.0.19045 Build 19045. After saving that ISO with this error not all components that I checked before are deleted.
System.IO.PathTooLong Exception: The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters. README.txt Toolkit requirements: "The ToolkitHelper.exe requires Microsoft .NET Framework 4.8."
Either VC++ integration is broken or VC++ related component removal is broken (or both or combination) for Win11 22621.963 because applications that depend on VC++ (such as MSI Afterburner) produce "side-by-side" or "1075" dependency error upon launch if: #1. All MSMG-allowable components are removed offline #2. VC++ is integrated offline I am still hunting down the exact cause, but if you do #1 + #2 offline, programs dependent on some VC++ versions do not launch and produce either "side-by-side" or "1075" dependency errors. That is reproducible. At least 2 programs are affected: - MSI Afterburner - YogaDNS
This seems to be no problem Replaced winre.wim on Windows 7 at C:\recovery with a Drive Snapshot WINPE (boot.wim) image renamed to winre.wim. Boots just fine to restore a backup. Same for any other (custom) WINPE image...
What's the point in this anyway? Sry for the guestion... Why not just create a (updated) install.wim and apply it to another partition/new drive. Add it to the boot menu using EasyBCD (like i learned here ) Then u can boot all windows...no hassle and no WINPE and no winre if u remove it. Replace WINRE with a custom WINPE(fix disk) to have a nice setup. Or just rip it out to safe some space?! and create another partition and extract (custom)WINPE there to have a recovery/fix disk It's never been easier like this... Keep up the good work here. It's like a machine
The entire point of removing WinPE is to reduce ISO size and system size (post-install). Boot Index 1 (WinPE) is basically bare-bone OS for troubleshooting, repair, deployment - something that most average users don't need. Boot Index 2 (Windows Setup Environment) is responsible for setup boot, system installation process, run cmd within it (Shift + F10), etc. Boot Index 1 (WinPE) size is approx 1.5 GB, Boot Index 2 (Windows Setup Environment) - 1.7 GB. The question is why after removal of Boot Index 1 (1.5 GB) there is almost no significant change to the boot.wim size and ISO size itself. I'm guessing, boot.wim compression is so high to the point where it doesn't really matter if Boot Index 1 (WinPE) is removed or not.
Hi @MSMG , Could you add `.empty` files to all the folders that are currently empty? This will help us in tracking changes between toolkit versions using git, as git does not track empty directories. Foe example, If I want to hard reset everything to v13.0 from v12.9, git reset --hard will clear all the empty directories causing me to forget the path to add features like `Packs/MultimediaRestrictedCodecs/w10/10.0.19041/` Simple way you could do this if you had WSL installed is , just before zipping it , from the root of the toolkit run Code: find . -type d -empty -exec bash -c "touch {}/.empty" \;
It's not like this. It's like mirroring with symlinks if the files have the same hash the size doesn't change anything. I remember that in the old days the winre of each index was repackaged and the hash of each one was different, making the iso bigger. Currently work in winre.wim is done only on one file. When saving, this file is copied to all indexes, and everything has the same hash, reducing the size of install.wim. Same case in boot.wim. when excluding winpe, it will only reduce the space of what is expressively modified for winpe to work. That's why the decrease in size is so small.
Writing in Portuguese, then translating to English always generates some misunderstanding. I thought that in that sentence "It's like mirroring with symlinks" I had been clear that it was an analogy. If the analogy doesn't fit well, that's okay. What matters is that with the rest of the explanation it was possible to understand. Or was it bad to understand? Maybe it's better to write it another way: "It's similar to the result when using symlinks". In other words, you don't have a duplication of data that would result in double utilization of storage space.