47 replies to this topic

[antonino61]

Hello folx,

I remember discussing *.etl proliferation on c:\ with wonko and alacrán once. there was no effective stopping at the time, as the system would automatically recreate them, thus augmenting used space (to the obvious detriment of free space on c:\. 

Well, now I think I got it done. it is still about resorting to the "infamous" primo ramdisk (or any other customizable ramdisk). In my case, even if u set it to the maximum, with the direct I/O and Dynamic Memory Management options, it will occupy as much space in ram as needed, so do not worry (in my case not more than 5gb in Z:\ (ramdisk)). the capture shows what directories want moving from C:\ to Z:\ and rejunctioning in the right places in C:\ ---> this means it will no longer be C:\'s problem, it will be Z:\ problem (ram, for all we care). at least we can count on an unbulging c:\.

nino

Attached Files

•  Capture4.PNG   587KB   2 downloads

[antonino61]

my latest vhd: 870mb --> lz4 260mb; still working without bulging

[antonino61]

one more caveat: in order to make sure everything is ok, I suggest u search for *.etl to make sure all of them reside in Z:\ (which means not in C:\); should any new etl file show its location on c:\, simply open primo ramdisk and make a new directory with the same name as the one the new etl file is in, paste it to the Z:\ location and rejunction it back on its original place. the event is rare, though, i.e. highly improbable, but still  possible.

nino 

[Wonko the Sane]

Hmmmm.

 

Idea 1:  set a fixed size for .etl files

Idea 2:  disable all or most obnoxious channels

 

Semi-random link:

https://www.nirsoft....nnels_view.html

 

Wonko

[antonino61]

Tx, Wonko.
If I have understood correctly, the software u propose enables the user to even stop .etl file creation. I can't get a full view of it 'cause I am not at home. I'M answering from a cell phone.
Nino

[antonino61]

Well, thanks to Wonko, I have managed to identify a windows\system32\winevt dir full of *.etl files; well, what I did was move it to z:\ and rejunction it to windows\system32 --> the etl files have now disappeared.

[antonino61]

another tiny bit of saving, ... well it could be a huge bit if u have big wallpapers in slideshow - solved this too. how? same method: the ram way. 

locate %appdata%\roaming\microsoft\windows\themes, leave slideshow.ini where it is but move the rest of the files u find to ramdisk z:\ and make symbolic links of them back to %appdata%\roaming\microsoft\windows\themes.

u will see considerable space and time improvements, even with big pictures.

cheers

nino

[antonino61]

2 more caveats, one concerning photo editing, the other periodic routine work on our part. 

1) with full vhd (wof-compress) and vhd.lz4 compression, when u open a picture directory, u might experience pictorial thumbnails immediately turning into indistinct neutral blank thumbnails, which is a bit of a nuisance; u might try working on ur photos more comfortably thru the plain vhd (not the lz4-compressed version); if it acts the same (blank thumbnails), try enlarging the vhd to 2gb, and of course leave the lz4 intact for later (when u have finished).

2) every now and then, it is convenient to make a general search for *.etl and $$* files: should u c any of them on c:\, reach the directories they are in, move them to z:\ (ramdisk) and junction them back into their original positions.

That is about it for now.

Pls, contribute to the stability in vhd used space size in any way u can.

nino

[antonino61]

My Dear Unprejudiced Vendetta, 

I agree with u totally and thoroughly on almost all points, so much so that I have already done what u have suggested here, but one thing - the installer (as most of these things are moved to ramdisk (which is nothing once u turn it all off) and junctioned back to their original positions (so they point to nothing in the end)): windows needs the folder in order to install anything or keep anything installed.

nino 

[antonino61]

sorry about the installer, vendetta, I misread ur post, now I see it more clearly, so 100% coincidence with what I already do, as my explanation points out, after all.

[antonino61]

for those of u who use Imdisk for ramdisk, here is a nice purge file for automating the ridding of *.etl and $$* files from the filedisk. unfortunately, the imdisk software is a little trickier for creating customized folders on startup, so instead of moving those files above into ram, u can delete them from a mounted h:\vhd and then lz4 it all (even if the system in ram recreates the same files and folders, who cares? once u shut it all down, upon next rambooting it will resort to the last version u had when u had booted in the first place.).

of course, the batch file might want extending when u have to rewimboot.

nino

Attached Files

•  purge.bat   1.39KB   1 downloads

[antonino61]

new purge.bat (including the deletion of the recycle bin)

Attached Files

•  purge.bat   1.54KB   5 downloads

[antonino61]

I realized some files and directories in the vhd can be erased without so much hindrance to the functionality of the system in order to make an even smaller vhd: bootmgr can be the one and only lonely file in the root dir (the other files are not needed); the boot dir in the root can contain bcd only (logs and other stuff not needed); the other boot dirs (in windows, windows\system32, etc, if any, are not needed); the only language dirs needed are the ones in windows, windows\system32, and windows\syswoa or something). Like this, you will not have the windows logo and the circle at the start and the visibility of the f8 bootmenu (the functionality still stays, so if u want to enter safe mode u need to go down to 1st, 2nd or 3rd option (safe mode, safe mode with networking and safe mode with command prompt respectively). u will have freed a few hundred kbs, though.

[antonino61]

I have managed to "purge" the services, little by little, with many trials and few errors. as Wonko once suggested, all u have to do is check the dependencies, both active and passive, and proceed with a backup copy of the vhd to revert to just in case something goes wrong. it takes a few hours but it is worth it.

[antonino61]

 

Well, now, after a few months of stability with the same wim+vhd combo, 4.8gb+1.5gb(lz4'd to 366mb)

(for which I can never stop thanking wimb for the usefulness of wimboot), I decided to try a win7 vhd for the sake of comparison. So many ppl say win7 is lighter than win10 so I wanted to scrape a few gbs and secs off the win10 wimboot deployments I mentioned above. 1 and a half day lost - well, nothing is lost in  experimenting - at least now we know that, on the same machine, there is an 8-second bootup delay between win10 (14secs) and win7 (22secs). I was surprised too, despite I have always been a purporter of win10 both in terms of space and in terms of time. win 7 takes more space than and twice as much time as I expected. This was tested after 1 and a half days of getting win7 to the same config as my win10s, not without issues though. the transition from post-install first boot to the most analogous configuration possible to win10 was one hell of an adventure with win7 (initial driver injections, incompatibilities, mismatches, system refractoriness to modification, etc.). there is very very much less to debloat, true, but it is paradoxically not as easy to take out whatever features one does not need as with win10. at the end of the experiment, I also wanted wimboot it to see if less space would factor in timewise. Like hell, it booted into  bsod, and the wim was no smaller than the win10 wims I have. As far as I can understand, whatever makes ppl believe win7 is lighter and faster lies in sheer Impressionistic Enlightenment. To those that say that microsoft has not improved its OSs from win7 onwards, I feel like replying that in fact it has with win10 in many respects, some of which I already mentioned in other posts. the flattened cosmetics has made it lighter and quicker than win10, at least from a mere user's point of view like mine. always ready for anyone who begs to differ, though. 

 

The harshest differer was wonko, who rightly reproached me for the OT kinda thing and laughed about the personal character of my remarks. Anyway, it is true that so far I have worked my way down from an initial win10 install to squeeze it as much as possible and a little up by adding my favorite software to let all the rest run on a portable basis outside the combo. 

If I remember correctly, wimb, wonko and alacrán the shrinker suggested in many ways I go from a winpe-like windows edition to work my way up by installing only what I have to and run everything else as portable. I realized I only did the second part I was suggested, because as for the former suggestion I have worked my way down. As I do not know how many services and folders can be still deleted from my above-mentioned wim+vhd combo, I realized I could comply with it now and try the opposite direction. I got hold of a winpe which is good in terms of apps and services, but as far as my IT knowledge allows me, it stays winpe, whence u move no way up. I would ask any of the aforesaid pundits if there is any way to turn a winpe into a primary, albeit small, os and restart from there. if it cannot be done, is there a smallest winpe-like win10 version available to start from?

[alacran]

For 7 try this way: http://reboot.pro/fi...ct-make-mini-7/

 

You may also try using 8.x for your test, then see this link: http://reboot.pro/fi...ct-make-mini-8/

 

Follow instructions on respective link, this will make very light versions of 7/8.x (don't use the smaller size option since it is very limited), also on each link there is a link to respective support post.

 

On 7 only versions capable to native VHD boot are Ultimate and Enterprise. On 8.1 I remember only Pro VL and Enterprise will let you maka a Windows to Go, but I really don't remember wich versions are VHD native boot capables. To avoid limitations and also Ramboot Firadisk or WinVBlock were used in the past.

 

Currently better use SVBus signed driver not Firadisk or WinVBlock, (only x64, x86 is unsigned).

 

I suggest do not use NTFS Compression, (it may cause future issues latter when installed as wimboot and compressed with lz4, this will give you a bigger VHD at the beginning but after wimboot install and lz4 compression will be fine), only install the strictly necesary programs or drivers, for additional programs prefer portables, latter you can capture it as Wimboot, make a new wimboot install to VHD and optionally compress the VHD with lz4_Compressor if you want.

 

My W864ESP1-WB.vhd.lz4 is only 109 MB.

 

But with some little tricks and a few luck (depends majorly of your video driver) I have made x86 versions to recognize more than 4GB of Ram:

 

W832ESP1-WB.vhd.lz4 is 80.3 MB & 10x86-WB.vhd.lz4 is 96.4 GB

 

See: http://reboot.pro/to...tpolicy +viewer

 

Only valid on first boot since the OS will undo the changes, but if Rambooting then there is no problem since your VHD or VHD.lz4 do not change.

 

alacran

[antonino61]

is there any such thing as 

VHD_W10_Compact - Make Mini 10

as well?

[alacran]

No.

[alacran]

But maybe you may try building your own, from a Win10XPE_x64, follow intructions on this thread from Misty: http://reboot.pro/to...npe-31-wimboot/

 

But adapt the instructions to Win10XPE_x64

[antonino61]

My Dear Alacrán, sorry for replying so late, but there has been some site recess here in reboot.pro lately. I was at pains trying to find u guys, but no dice. Anyway, I did get hold of win10xpe_x64 and did try to follow misty's instructions, but to little or no avail. I actually do not know how to make a transition from winpe to a workable version of windows.

Back about ur previous post, u mentioned wimb's mini8 and said there was no mini10 at present. Do you know whether wimb is planning to may a mini 10 program? I did try mini 8 on my windows 10 combo (vhd+wim) and even on a standalone vhd, but to no avail (logonUI.exe buffer overrun error). I did have a try because, on my umpteenth vhd+wim update baking, I got wimboot automatically naming my windows 10 w8something.wim instead of the usual w10something.wim. It had never happened before. Let us see what wimb might say to this.  

In general, a few gigs less than my wim is now (3.8gigs) would be great (with mini 8 (unfortunately it does not work) I reached as little as 1.7gigs with the same stuff inside (as it was, without modifying it, I mean). As for the vhd (standardized at 1.5gigs by wimboot) attached to the 3.8gig wim, I was able to lz4ize it to 255megs, which is 2ce as big as yours. Consider, though, that I have a videocard whose 500megs install takes about 2gigs on the drive, plus the I9 processor, my gigabyte aorus mobo, etc: do u think I can ever reach ur tiny sizes with whatever shrinker at all?

[antonino61]

Anyway, for better compression, try Compact+LZX.exe on the overall standalone vhd, before wimbooting it. in my case it went from almost 15gb to 5ish-gb of used space. then u can apply the resulting wim (less than 4gb) to a 1gb vhd and make it work fine. Even better if u first compress it with wof-compress and then compact it with the exe above, of course before baking a wimboot combo out of it. the term I normally use to set the minimal disk space on the vhd is if I can view picture thumbnails ok; if I see just blanks, that means that the vhd wants enlarging. the good thing is that after this combined wof compression and compact+lzx.exe run u will be able to bake a wimboot combo whereby the used space on the resulting vhd will not change, if u do not install any further software, of course - at least here. In addition, u can also use the compact-lzx.exe tool from the command line, as in " compact /c /s /a /i /exe:lzx "v:\*" " after wimbooting, where v:\ is the vhd letter.  u can get an easy 800mb-or-even-less vhd to boot from. 

don't use wofcompress on the vhd when it is already attached to the wim, as it will "bulge to red";

don't use the above command line on the wim file either, as it will be unusable afterwards.

[antonino61]

For what I have been able to experiment so far, u can compress (or better still shrink) ur used space on the vhd as much as u like, but once a certain file of them gets written to, it will bulge to its natural size. I do not think it will return to its compressed size once "released" by the system. If I am correct, I don't know if anything can be done to "tell" the system to shrink it back again, though. it would also be interesting to experiment any smaller size than 1gb if wimb could enable smaller size vhd applying in wimboot. Unfortunately I do not think I am in any position to say whether or not it can be done. Only wimb, as the one who made the tool, should have the last say. 

[alacran]

On any wimboot environment once a file changes it stops been a pointer to the source .wim and it becomes a real file with real size, same apply to all new files, there is no way to avoid this, only thing you can do is recapture a new .wim and make a new wimboot install.

 

That's why it had problems on devices with only 16 GB of SD storage and on 10 appeared the Compact mode install, this wimboot mode is almost deprecated now, but nevertheless actually it can be used Rambooting it as another option for service and repair PCs just as a WinPE but having all advantages of a full system.

 

It may be also usefull if you install before capturing it as wimboot all the programs you will use and do not install anything else later. You may Ramboot it without the need of any AV and do not have any risk, since every boot it is loaded to Ram from an pristine unchanged VHD.

 

I made some tests with VHD files of 512 MB and 1 GB size, and they have a very hight tendency to freeze (I intentionally ran tests on a 4 GB PC), 1.5 GB also could have this problem on some 4 GB systems but it is not very common, since my goal was find a size to Ramboot on 4 GB of Ram systems (wich actually almost all PCs have), this is the maximum size that can be Rambooted on that Ram, I was able to boot 1.7 VHDs but taking in consideration the available Ram varies a lot depending of the Ram reserved for video it is better to be conservative and 1.5 Gb is a good size.

 

You may run your own tests on smaller size VHDs but you will have to do it manually, and better use wimlib to capture and deploy the OS.

 

I don't think wimb is going to change the 1 GB minimum size for the VHDs on his tool. Also I know he likes and recommends 4 GB VHDs.

 

alacran