444 replies to this topic

[alacran]

@ antonino61

It is always same thing, you always do everything to your own way, and can't follow instructions, and latter when nobody knows what the hell you did (many times including yourself), you starts saying something do not work fine, then it is very difficult to try to decipher what's the problem or reproduce it, to try to help you.  And additionally almost all you messages are cryptic and hard to understand.

 

I esteem you, you have a lot of good disposition and are very friendly, but sometimes you make me get crazy.

 

You sould start from scratch and following exactly a known procedure:

1. Fresh Install by means on WinNTSetup. NOT using a previously captured WIM, use the MS WIM file.
2. Add favorite programs and SVBus driver. (here you should make a list of files, before and after adding your programs to find latter what else you need to keep to let them work fine).
3. Capture and re-apply using VHD_WIMBOOT (keeping the WIM file for future use in case of need). Recommended in this case as you are having issues.
4. Reduce the VHD using ONLY Win_Reduce_Trusted last version, just as it is, with no changes to any list.
5. Capture and re-apply using VHD_WIMBOOT (keeping the WIM file for future use in case of need).
6. Test new VHD.

No. 3 can be avoided when all is working fine.

 

On Nos. 3 and 6 use the standard WimbootCompress.ini on the program, download VHD_WIMBOOT again and use the just downloaded program, not the previous modded version you have.

 

But DON'T add or remove anything manually, just use Win_Reduce_Trusted, I know some of your programs will not work but comparing the lists made on No. 2, it will be easier to find what is required to make them work, and then all required can be added, keeping a list of this additions that latter once all is working fine it will be used to modiffy the Win_Reduce_Trusted  lists for future use. And please DO NOT edit the Registry, also avoid additional Ramdisks for now.

 

This way we may be able to help you, if you do not follow this instructions exactly and with no variation it will be a dead end.

 

alacran

[antonino61]

administrator is just the name I give my user dir, the same as Antonino; shall I change it? it contains the normal user content.

 

@alacrán

I did try ur deletesysvol kinda thing, and I enthuse at not having any disaster or catastrophe here. I only do not see any difference between the result of ur batches and what I had before, that is to say a directory containing a zero byte file. the directory is zero bytes too. btw, what is the aim of the procedure? i guess this zero byte file and directory has been there, dormant I guess, for the past few years. am I wrong?

 

As for the procedures u have suggested, I have followed all of them, and a bit more, if anything goes wrong with the registry, do not forget I still have a backup copy anyplace else to be copied back to the original position, if need be, and restart from the latest step taken. I really do not see any difficulty trying to help each other.

[wimb]

administrator is just the name I give my user dir, the same as Antonino; shall I change it? it contains the normal user content

 

The name Administrator is not the problem, but it does not contain (anymore) the normal user content.

Probably folders Searches, Contacts and OneDrive have all been removed before Win_Reduce_Trusted is used .....

 

In any case you managed to make Win_Reduce_Trusted to fail in finding Your UserFolder ....

 

Here there was another case where UserFolder was not found, but that was because Windows was never Installed 

After using WinNTSetup he did not Reboot for Install of Windows, but instead directly tried to use Win_Reduce_Trusted   

[antonino61]

searches, contacts and the other stuff u mentioned, I eradicated them as I do not need them (I might as well readd them), this is what I did do. what i did not do is what u said last, i.e. run winreduce before the install procedure automatically created the account - no such thing here. of course I did it later than that. Once I tried running winreduce soon after the install had finished, which led to the same inconvenience with the files I want to run. in order to preserve functionality I realized it would be better to run winreduce as late as possible and re-add manifest folder and root content to winsxs and syswow64 respectively. the rest that applies to my system runs fine. I do not know where alacrán got it that something does not work here. I am only trying to get the greatest functionality with the minimum impact. As anybody else might do, I suppose.

[antonino61]

Well I have re-installed the same build from scratch one time around, as wimb and alacrán said to do, and ... this time it has worked, but then again, if I do not want to do without a couple of pieces of software, I need to copy manifests and root files back to winsxs and syswow64 respectively. the rest works fine, it is customizable and it responds well if u don't mistype. of course, I am not bound for the most extreme reduction possible (I need directx and net.framework and I am going to make use of pstart.exe now and then; the portable apps start interface is too good to do without, I think). What is very very handy is the couple of applets alacrán provided (send to + links and the sysvolinfo zeroer); the latter was particularly good for replication in the case of other directories that would otherwise be recreated (i used it for softwaredistribution, sleepstudy and logs and they have stayed in the form of 0byte files so far; I guess it could be applied to other stuff that I sent to ram and found nothing of, but I am not sure it is a good idea to apply the same procedure to those directiories I see populated with something in ram). I winreducetrusted this build BEFORE making a ramdisk. I remember telling u guys once that I  saw the difference between the reduced winsxs manifests and syswow64 rootfiles and what more my software requires from those folders; I already told u that the difference was only 30 megs which I once copied back to their original locations but to no avail, as some files (mostly dlls) could not get re-registered. the files (I still keep them) were gathered following process explorer listings. I also went so far as to try putting those dlls in the roots of the apps concerned - noway, they are expected to be in windows. as soon as I find some alternatives to the software I dont wanna get rid of I will definitely retry the winsxs and syswow64 reductions without the readditions.

[alacran]

Good, very fine, I liked you followed the instructions this time, and got good results, of course with the exception of the folders/files you need to keep for some of your programs, which is fine.  I'm glad all is working fine.

 

The 0 bytes file trick is a way to avoid sending folders (making Directory Juctions) to a Ramdisk, and better send the new LOG/ETL files, (that have that folders as target), to limbo. But unfortunately it is not possible to do it in all cases, there is still some info that the OS needs/has to write to certain folders, but at least now we are able to keep it to the minimum possible (about 2 MB only).

 

alacran

[antonino61]

what is the limbo in computer lingo? how do I send anything to limbo? what command line instruction do I need?

 

As regards 0byte files, I have just noticed that, e.g., \windows\logs, \programdata\softwaredistribution and c:\$recycle.bin stay 0 byte files, whereas \windows\softwaredistribution and c:\SystemVolumeInformation get recreated as folders but still staying at 0 bytes. I haven't looked at other instances of the kind yet, though.

[alacran]

It is just an expression, quite common on my mother tongue, (meaning no-where or to nothing), there is not a command to do that.

 

In my case none of the folders has being re-created, the re-created folders may look as 0 bytes content, but if you gain access to them you will see usually they are not empty.

Or you can also check that, booting from Win10XPE_x64, attaching the Mini-10.vhd, and check properties and/or open the folders.

 

alacran

[antonino61]

i got inside them and found nothing, not thru winpe though. y si mandas algo a la chingada de forrma metafórica, por qué no mandarlo a la ram de forma real? De tal forma se fuera doblemente a la chingada, ?o no?

[alacran]

First let me tell you, your Spanish is improving.

 

Just to be sure, you have being talking of SystemVolumeInformation but the name is: System Volume Information.

• Are you sure you used the right file name?
• Did you captured and re-apply the VHD?

 

If so, that may be the resaon, the \System Volume Information is on internal [ExclusionList] of wimlib-imagex and also Dism,.

 

You can't send \System Volume Information folder to a Ramdisk, if you do it the OS will give you troubles during boot.

 

The \System Volume Information 0 bytes file has to be created every time you make a new installation, so far to not have to create it I have a copy of it and just copy it to the root of the just deployed VHD, before unmount it the first time.

 

But during writing this I got the idea to include it manually on the WIM file after capture by means of wimlib-clc. I will check this approach.

 

About the \windows\softwaredistribution folder I think it depends of your update settings, (on my case Updates and Update Service are set to manual), send this to Ramdisk if you want, doing it should not create problems.

 

I do not use any additional Ramdisk, I don't need it, as always boot the Mini-10.vhd on Ramboot mode, so nothing is written to the original VHD and it remains unchanged for ever.

 

alacran

[antonino61]

Almost all of the above makes sense. of course i copied the right file and/or folder name in each case. when I write here I might type it wrong. I almost made a catastrophe last night with sending system volume information to ram and told u about it and came back to warn u as soon as I could - not only booting problems but also folder recognition problems. thank god I solved it by restoring them 1 by 1. almost all of them only contain a zero byte file about mountpoints: one of them also has some 1 byte wps* file. to be precise, at least on the vhd, the folder has always shown its zero byte size for years, way before your procedure was applied - no evident difference. on the other drives, the correction of yesterday's mistake of mine led to a Oing of the folder on all drives but the one with 1byte. i always have a copy of the zero byte file which I passed around. No I have not gone thru wimboot yet, as I am just after further pruning the vhd with the procedure described on get-alladafluff-out, the only difference being this time I did not touch registrar registry manager; i only acted on the vhd by erasing the unneeded files and folders. I dont wanna read preposterous, but this step has shrunk the used space by 1.5 gb. so far it has worked like a charm. I will wim it tomorrow.

[wimb]

Thanks, I will change all the layout of my Y: drive to be consistent with your proposed Structure. Only thing I will add to it is FirefoxPortable on the root of the drive as VLC is.

 

In the meantime I was looking to further reduce the creation of ETL and LOG files, and I made this batch file that I ran from the VHD as TrustedInstaller using PowerRun, as some folders may be protected.

 

Safe-to-Replace.bat:

@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 "%ProgramData%\Microsoft\Windows\wfp" /s /q
rmdir "%ProgramData%\USOShared\Logs" /s /q
rmdir "%WinDir%\SoftwareDistribution" /s /q
rmdir "%WINDIR%\Logs" /s /q
rmdir "%WINDIR%\System32\SleepStudy" /s /q
;
; Following files will be created only if there in not a folder or file with same name
;
fsutil file createnew "%ProgramData%\Microsoft\Windows\wfp" 0
fsutil file createnew "%ProgramData%\USOShared\Logs" 0
fsutil file createnew "%WINDIR%\Logs" 0
fsutil file createnew "%WinDir%\SoftwareDistribution" 0
fsutil file createnew "%WINDIR%\System32\SleepStudy" 0

Exit

 

Removal of these folders and Replace with Files without bytes is working.

In case of System Volume Information then the zero byte file is replaced again by the folder when Unmounting and Remounting the VHD

So System Volume Information is not a useful item and besides it can contain important information regarding connected WIM file in case of WIMBOOT.

 

After Removal / Replace then Capture followed by Apply results in wim-lib Apply error

I think may be it is better not to replace these Folders by zero byte Files.

Anyway the advantage is may be not worth all the troubles that we may get .....

 

In the mean time the program Win_Reduce_Trusted was improved as to allow selection of a Custom Command Item

that can be useful to use Custom_Command.cmd file comparable to the one given above ...

For the time being I have disabled Removal / Replace by using ECHO in front of the commands RMDIR and FSUTIL

 

Also the detection of User is improved so that problem of antonino61 will not occur ....

 

Download:  Win_Reduce_Trusted-35 

 

 Win_Red_35_Error_2020-11-11_090132.jpg   67.16KB   0 downloads ==   Win_Reduce-35_2020-11-11_095542.jpg   65.64KB   0 downloads

[antonino61]

sleepstudy gets recreated.

[gbrao]

If you ever need to delete a folder or file as TI.

 

Credits : NSudo | System Administration Toolkit
https://m2team.github.io/NSudo/en-us/

AU3 source and exe in attached zip.

 

There's no GUI as such so no screenshot.

 

EDIT : Fixed a bug in DeleteFileTI. New attachment DeleteAsTI_20201112.zip.

Attached Files

•  DeleteAsTI_20201112.zip   1.04MB   2 downloads

[wimb]

sleepstudy gets recreated.

 

Removal of the relevant dirs followed by Replace with zero bytes File is Disabled since it results in wimlib Capture / Apply error ....

[wimb]

If you ever need to delete a folder or file as TI.

 

Credits : NSudo | System Administration Toolkit
https://m2team.github.io/NSudo/en-us/

AU3 source and exe in attached zip.

 

There's no GUI as such so no screenshot.

 

Thanks and certainly interesting,

 

but the present program Win_Reduce_Trusted is launched already as Trusted Installer and allows to delete folder or file as Trusted Installer

[antonino61]

I have tested this version too and it it working fine.

[wimb]

I have tested this version too and it it working fine.

 

Good that the problem is solved .... 

[wimb]

Mini 8.1 x64 made with Win_Reduce_Trusted is working OK

 

 Win_Red_81_2020-11-11_141341.jpg   141.36KB   0 downloads

[alacran]

Thanks for the new version my friend.

 

Removal of these folders and Replace with Files without bytes is working.

In case of System Volume Information then the zero byte file is replaced again by the folder when Unmounting and Remounting the VHD

So System Volume Information is not a useful item and besides it can contain important information regarding connected WIM file in case of WIMBOOT.

 

After Removal / Replace then Capture followed by Apply results in wim-lib Apply error

I think may be it is better not to replace these Folders by zero byte Files.

Anyway the advantage is may be not worth all the troubles that we may get .....

 

In the mean time the program Win_Reduce_Trusted was improved as to allow selection of a Custom Command Item

that can be useful to use Custom_Command.cmd file comparable to the one given above ...

For the time being I have disabled Removal / Replace by using ECHO in front of the commands RMDIR and FSUTIL

 

Also the detection of User is improved so that problem of antonino61 will not occur ....

 

 

Good, this allows to apply the commands after capture and re-apply.

 

Usually I boot from Win10XPE to apply the reduction, and capture the VHD after reduction (without applying any of the 0 bytes files), using wimlib-clc, and then inmediately after re-apply using wimlib-clc, I copy the System Volume Information 0 bytes file before it is created  and apply the commands.

 

Then as I always apply the commands after capture and re-apply, never had troubles with them during captue and re-apply, about the System Volume Information, the file I use to copy to the VHD root during my tests is Read Only and also Hidden, and after booting several times as filedisk for testing pourposes, (from VHD into internal HD), none of the folders including System Volume Information was re-created,

 

And yes, I'm agree it is not a good idea to replace System Volume Information folder if planning to Wimboot.

 

From this post: http://reboot.pro/to...-15#entry217022

 

I think the System volume information trick should be added too: http://reboot.pro/to...e-2#entry216348, on that folder (if exists) is created DiagTrack.log and other items, also the folder content grows a lot. It is better to avoid its re-creation.

 

NOTE: This trick is not recommended for Wimboot mode installs, as that folder may content some info required to locate the linked WIM file.

 

alacran

 

 

alacran

[alacran]

@ wimb

 

It is good to know Win_Reduce_Trusted also works on 8.1

 

alacran

[antonino61]

In the mean time the program Win_Reduce_Trusted was improved as to allow selection of a Custom Command Item

that can be useful to use Custom_Command.cmd file comparable to the one given above ...

For the time being I have disabled Removal / Replace by using ECHO in front of the commands RMDIR and FSUTIL

 

Excuse me, Wimb, where is this custom command to be placed in order for win_reduce_trusted to make it effective?

[alacran]

@ antonino61

 

Win_Reduce_Trusted-35\Win_reduce\Custom_Command.cmd (no need to move it).

 

To let it be applied, you need to remove the two ECHO, (Open the Spoiler and see them remarked in blue letters)

 

Spoiler

 

:: ========================================================================================================
:: ====================================== Custom_Command.cmd - November 11 2020 ========================
:: ========================================================================================================
@echo off
Setlocal EnableExtensions EnableDelayedExpansion

set WorkDrive=%1

ECHO.
ECHO WorkDrive = %WorkDrive%
ECHO.
if not exist %WorkDrive%\Windows\System32 (echo WorkDrive Not Found - Error: %WorkDrive%\Windows\System32 Not Found &pause &goto :eof)

ECHO  *** Remove some Folders and Replace by File without bytes  - Diabled by using ECHO ***
ECHO.
rem  to avoid the potential re-creation of the folder and this way send new ETL/LOG files to limbo
ECHO.
rem pause
ECHO.

FOR %%A IN (
  "%WorkDrive%\ProgramData\Microsoft\Windows\wfp"
  "%WorkDrive%\ProgramData\USOShared\Logs"
  "%WorkDrive%\Windows\SoftwareDistribution"
  "%WorkDrive%\Windows\Logs"
  "%WorkDrive%\Windows\System32\SleepStudy"
) DO (
  ECHO RMDIR %%A /s /q
  ECHO IF NOT EXIST %%A FSUTIL FILE CREATENEW %%A 0
)

ECHO.
ECHO  *** Custom_Command - Ready ***
ECHO.
rem pause

goto :eof
:: ========================================================================================================
:: ====================================== END Custom_Command.cmd ======================================
:: ========================================================================================================

 

 

NOTE: Remember to run it ONLY after capture and re-apply or you will have troubles during re-apply.

 

As mentioned here: http://reboot.pro/to...-16#entry217046

 

Removal of the relevant dirs followed by Replace with zero bytes File is Disabled since it results in wimlib Capture / Apply error ....

 

 

alacran

[antonino61]

ok thanx

[antonino61]

Well, what can I say, windows 10 in less than 2.3gb in spite of all my whims, ... ain't that something?! This is a new era, and I insist on its deserving sound recognition and the start, growth and development of new desktop trends. Attaboy to all, especially to wimb for his flying pragmatism in action, alacrán for his geriatric warnings (lest catastrophes should occur) and wonko for his sober notions and poignant concepts.