Posted 08 September 2020 - 08:36 AM
further OS shrinking achieved: mail, sidebar, hyper-v, onedrive, tabletpc, parental controls, windows store, xbox, office, edge, cortana, cloudexperience, internet explorer, retaildemo, smart card, pointofservice, narrator, search, gpuejectdialog and defender are disabled on debloating the system, but they are not physically removed from the vhd. u can complete this task later. all u need to do is copy your vhd someplace else just in case something goes wrong, have takeownership active and delete all instances of the listed components from ur vhd. each time u delete one u have to get registrar reg manager to delete the corresponding registry entries and then use registry first aid to readjust, readdress and remove the links as it sees fit. it is a tedious task but u perform it only once.
Posted 19 September 2020 - 03:28 PM
Posted 20 September 2020 - 03:51 AM
I commented my procedure on: http://reboot.pro/to...e-7#entry215500
It is valid for Wimboot and Compact installs
Also it is a good practice to remove all garbich with CCleaner and then make a full defragmentation with Defraggler before recapture.
As said, a lot of unwanted things can be removed safely from the install.wim since the begining, before the first installation using MSMG Toolkit, there is no need to do it manually after installation and using brute force.
Just read carefully and completely the instructions on included README file.
- antonino61 likes this
Posted 20 September 2020 - 01:39 PM
some things, actually the albeit sheer majority of them, cannot be removed in advance, though, at least with my means. so brute force is the only way when this is the case. even the junctioning of things out to a ramdisk is, in a sense, brute force. but, what else can we do? of course, what I have been able to remove your way in advance, I already have. but there still are some things which have not been removed. other things have had their functionality removed, but they are still physically present.
Posted 28 September 2020 - 01:22 PM
I can confirm that the removal of the list works on other 19042 builds. this time, to make it as close as possible to the end of the install process, I made the deletions right after the completion of driver setup to have everything in order in device manager. it is actually the same as doing it later, but it works in the end. so let us recap the list:
mail, sidebar, hyper-v, onedrive, parental, windowsstore, xbox (no registrar deletion, only files and folders, pls), office, edge, cortana, cloudexperience, internet explorer, internetexplorer, retaildemo, smartcard, smart card, pointofservice, narrator, search, xgpuejectdialog, defender, paint, snipping, update, perceptionsimulation, servicing (leave the trusted installer executable, though), defrag, backup, restore.
all these but xbox (see above) need to be erased in the registry thru registrar registry manager, and then its contents need to be deleted from the disk (files, folders and any occurrence). the links should be readjusted by registryfirstaid.
the whole process took me about 4 hours. I am sure everything could be eased by a few scripts.
Posted 29 September 2020 - 12:50 PM
another big space user is the software of a powerful videocard which comes bundled to the drivers. the videocard driver install can be shrunk any further by [Guru3D.com]-NVSlimmer (in my case it is a nvidia card, but I am positive u can find its ati parallel on guru3d.com). better is to install the drivers after the slimming down process.
after that, at least as far as nvidia is concerned (I don't know about ati, so dont try if u dont feel like, or do try if u have already backed up ur vhd), u can delete all possible content from \program files\nvidia and \...\nvidia corporation, \program files (x86)\nvidia and \programdata\nvidia and \...\nvidia corporation - dont even try to delete what u have not been able to because it is already open in taskmgr.
Still for nvidia cards (again, I dont know about ati), I found nvcleaninstall.exe (I unfortunately do not remember where), which can do the job above by simply enabling u to select what to install (I would choose only the drivers, which include the control panel that u can adjust some features from) + enable or disable some features, all this straight from the exe file from nvidia. I guess this solution is the better one.
Posted 13 October 2020 - 05:33 PM
here is another one of the branches that want pruning - recovery, so type recovery in swiftsearch and get it outta the disk, then type recovery in registrar registry manager and get it outta the registry.
Posted 14 October 2020 - 07:14 PM
well, while trying the pruning of another build to see if it works I just came across another bunch of branches to hopefully get rid of - by running bloatbox, I noticed a whole list of "modern" bloating apps to try to delete; well, some it does delete, while others it cannot. among the latter, I found a couple of apps that belong to the list I posted above, which I got rid of in the way described. the rest of them, I will try and see if I can delete the old way. I will tell u the ones I have managed to erase. If u r eager to try urselves, do as I did and start from the first and work ur way down the bloatbox list. see u later.
Posted 25 October 2020 - 11:25 PM
most items in the windows accessories section of the start menu can be gotten rid of as well.
Posted 09 November 2020 - 01:14 AM
the same as above applies to bluetooth and touch, of course if u use no bluetooth or touch devices.
Posted 04 December 2020 - 08:29 PM
I have recently found out that the bitlocker stuff can safely be taken out as well.
Posted 28 December 2020 - 07:53 PM
I have also found out that, by means of process explorer, I can learn what syswow64 dlls a favorite program needs in order to work ok. then, copying them to a safe place before running winreduce and then copying them back later can make that favourite program work even with the reduction (it is technically the same as copying back all files from the syswow64 root, the only difference being the space occupied). the procedure works 7 times out of 10. at the end of the day, i have reached vhd and wim sizes closer to the ones wimb and alacrán have advertised without any "nostalgic suffering". the reduction I am talking about does not concern winsxs (I am still copying manifests back to its original position to make everything work, as before). but if u only have a couple of favorite programs, the syswow64 reduction gain is at least half a gb on the vhd and a bit more on the wim.
Posted 09 March 2021 - 11:06 PM
getting back to trying to shrink the system2 folder any further than winreducer has already done, I have just discovered that it is not safe to delete and zero the spp subfolder, e.g., thru powerrrun in the following way:
Posted A week ago
btw, I have just discovered that instead of getting rid of the cloudexperience stuff, it is alternatively just as safe to type only "cloud" into the swiftsearch hatch and get rid of all the stuff that lists below (cloud, cloudapcache, cloudstore and cloudexperience, which means killing 4 birds with 1 stone), provided the onesettings folder content has been saved elsewhere in advance and is copied back to its original place after the cloud stuff chopping. the onesettings folder contains some files which are crucial to the opening and functioning of the settings panel (win10's new control panel).
Posted A week ago
I have just found out that most \windows\inf subfolders can be safely removed and that the driverstore subfolder can be shrunk even further - while in your online vhd, just eliminate all possible (don't try to force the deletion of the open ones) subfolders but the graphics card one, which u can move elsewhere and junction it back to its original location (it is the largest subfolder in the filerepository directory (about 500 megs in my case). these two operations can save about 600 megs on your physical vhd and still be valid for all other windows versions, as your video card driver stays the same, no reinstallation is required across the various vhds you have, which will delve on the same data that you will have junctioned to each vhd as explained above (instead of having this half a gig on each vhd, u can have a common one elsewhere, off the vhd).
Posted A week ago
In my case of Mini-10x64 the nv_dispi.inf_amd64 subfolder of DriverStore\FileRepository is excluded with Win_reduce\File_List\remove_sub_DriverStore.txt
Also the .NET subfolders of \Windows\INF are excluded with Win_reduce\File_List\remove_MS_NET.txt
Indeed it is ver useful to mention the specific nv_dispi.inf_amd64 and helloface.inf_amd64 subfolder in Win_reduce\File_List\remove_sub_DriverStore.txt
since they occupy a lot of space and can be excluded from Mini-10x64 VHD
- antonino61 likes this
Posted A week ago
thank you, Wimb, I have also found out that the whole driverstore can reside elsewhere to save even further space (and time for the laziest, and probably wisest). as regards nv_dispi.inf_amd64, here it has not gone away with winreduce (probably on account of my having to untick the .net stuff on the list of options?). I also have tried including nv_disp.inf_amd64 in the general file repository chopping, and the system does boot ok, but the graphics and other funcionalities (directx and .net) are compromised. that is why I initially advised excluding it, before finding out that the whole of driverstore could be moved elsewhere with no hindrance to the system. In general, I can say that these procedures also come in handy when dealing with graphics driver updating, as they keep the parameters even across various vhds and spare the expanding and reshrinking due to the graphics driver's bulkiness.
as for helloface, I guess it has gone away as a result of service chopping (device remover or brute force, I don't remember well).
Posted A week ago
one thing must be said, though, which will please my learned friend alacrán (who wants to have it together all in one place) - after these procedures, the lz4 compression of the full vhd with driverstore outside is not so extreme (only a few hundred megs) as is the case with the full vhd with driverstore inside.
Well, before Alacrán gives me the usual what-for, I have to admit being lured by a time-saving mirage for the past few days - overwriting a previously-made vhd with a more recent wim; it does work ok, but it does not take full advantage of vhd_wimboot's shrinking properties. now that I happened to lz4 a fresh vhd I noticed the usual 1-gig difference between the vhd and the lz4. so, as usual (albeit not always), I have put a foot on my mouth once again. I take my advice back and suggest applying wims the old way, as wimb has always recommended.
Posted 5 days ago
By the same token as the driverstore folder, also other folders can be made "common" across various builds by placing them elsewhere and junctioning them back to their original places. it is the case with Program Files, Program Files (x86) and programdata, Assembly, installer, media, microsoft.net, textinput, vss and winsxs from the windows folder and advancedinstaller, dism, F12, inputmethod, keywords, setup, shellexperiences, wbem, windowspowershell and winmetadata from the windows\system32 subfolder can be "exported". the whole directory tree amounts to over 3gb which is reduced to half its size and serves various builds which have gone smaller as a result. the space occupied is a lot lesser this way. two criteria have been applied to the choice - folder impact and feasibility, in the following fashion. if the impact is huge, let us see if they can serve all these builds; if the impact is slight, why bother trying to see if it is feasible? v.i.z. the wimb way.
Posted 4 days ago
well, the initiative described above yielded a decrease in space footprint and a few seconds longer in some bootup times; let us see a few figures:
the external common core (program files, program files (x86), programdata, windows) that I was able to safely accunulate outside th vhd (in order to have it serve 4 vhds on a common basis) amounted to 1.2gb on disk. as a result, I was able to shrink the 4 vhds from 2.8 to1.5gb each (lz4), for a total 7.2gb (1.5x4 + 1.2) footprint, as opposed to the original 11.2Gb (2.8x4). wimbootwise, 1.2gb (outer common core) + 1.4x4 (wims+ gzipped vhds combos), for a total footprint of 6.8gb; the wimboot combos before this shrinking initiatives had an overall fooprint of 10gb (2.5x4).
full ramdisk bootup times fell from 28secs to 22secs, whereas wimboot combo ramdisk bootup times went from 12secs to 14secs (only 2 seconds longer bootup times).
1 user(s) are reading this topic
0 members, 1 guests, 0 anonymous users