Jump to content

Winapp2.ini additions


Winapp2.ini

Recommended Posts

  • Moderators

so what does this do exactly?

Adds additional rules (specific programs and locations) for ccleaner to clean

 

ADVICE FOR USING CCleaner'S REGISTRY INTEGRITY SECTION

DON'T JUST CLEAN EVERYTHING THAT'S CHECKED OFF.

Do your Registry Cleaning in small bits (at the very least Check-mark by Check-mark)

ALWAYS BACKUP THE ENTRY, YOU NEVER KNOW WHAT YOU'LL BREAK IF YOU DON'T.

Support at https://support.ccleaner.com/s/?language=en_US

Pro users file a PRIORITY SUPPORT via email support@ccleaner.com

Link to comment
Share on other sites

I have searched the HDD and found several BAK and TMP files. Please do incorporate the folling into the winapp2.ini

...

[Twain Temp Files*]

LanSecRef=3021

DetectFile=%WinDir%\twain_32

Default=False

FileKey1=%WinDir%\twain_32|*.tmp

 

On my PC running Windows XP, the above entry, included, I believe, in winapp2.ini v4.00.130412, broke scanning

software for my HP printer by removing registered TWAIN Data Stub DLL/Module file

 

C:\WINDOWS\twain_32\hpqgnds2.tmp

 

which has an unfortunate filename extension for a registered file, and forced me to recover file/reinstall scanning

software from HP installation CD to get scanning software working again.

 

Please remove this entry for [Twain Temp Files*] from winapp2.ini or add severe warning that this will break HP printer

scanning/digital imaging software.

 

Thanks in advance! :)

Link to comment
Share on other sites

Thanks for the update.

 

You added the entry [Miranda IM Cache*] twice.

 

And I think that you overlooked my comment:

 

I recognized that some of the ExcludeKeys don't work. Conclusion: If you exclude a single file only (without a wildcard *), you have to use a backslash instead of the pipe symbol.

 

Here is an example:

ExcludeKey1=FILE|%ProgramFiles%\ProgramXY|file.exe (does not work)

ExcludeKey1=FILE|%ProgramFiles%\ProgramXY\file.exe (does work)

 

The pipe symbol is necessary if you use a wildcard (*) or a separator (;):

ExcludeKey1=FILE|%ProgramFiles%\ProgramXY|*.exe;*.log

 

The following entries are affected:

 

[AI Roboform*]

[jv16 PowerTools 2011 Backup Files*]

[jv16 PowerTools 2012 Backup Files*]

[jv16 PowerTools 2013 Backup Files*]

[MS Office Word More*]

[Oxygen 14*]

[Photodex ProShow Producer*]

[PS3 Media Server*]

[TVersity*]

[VMware Player*]

[VMware Workstation*]

Link to comment
Share on other sites

This apparently works as well

 

ExcludeKey1=FILE|%ProgramFiles%\ProgramXY\|file.exe

Windows 10 x64 Pro on ASUS Maximus VIII Extreme motherboard, i7-6700k CPU,H220 X2 Liquid Cooler, 64 gbyte RipJaws DDR4 3200 RAM, Samsung 970 Pro NVMe M.2 500 gbyte SSD + Samsung 850 Pro 512 gbyte SSD, EVGA RTX 3060 Titan graphics card (Home Built System);  Windows 11x64 Pro on 512 gigabyte Dell XPS 15 2-in-1 Laptop/tablet and Dell XPS 8940 PC.  ASUS RT-AC88U router, 14 tbyte WD My Cloud PR2100 NAS Server, 200 Mbps cable Internet, MS Edge Chromium, MS Office 2021 (Local), Casper 11, DisplayFusion (3 Flat Panel Displays per system):   Latest Bitdefender Internet Security, Quicken, Weather Watcher Live, ThumbsPlus 10, Sticky Password 8, WD Smartware, CyberLink PowerDVD23, MSI AfterBurner, Rainmeter, 8GadgetPack, and many more.

Link to comment
Share on other sites

Modified Removed RegKey3 (aggain) and other minor improvements

 

[Adobe Reader*]
Section=Windows 8 Apps
DetectFile=%LocalAppData%\Packages\AdobeSystemsIncorporated.AdobeReader_ynb6jyjzte8ga
Default=True
FileKey1=%LocalAppData%\Packages\AdobeSystemsIncorporated.AdobeReader_*\AC\INetCache|*.*|RECURSE
FileKey2=%LocalAppData%\Packages\AdobeSystemsIncorporated.AdobeReader_*\AC\INetCookies|*.*|RECURSE
FileKey3=%LocalAppData%\Packages\AdobeSystemsIncorporated.AdobeReader_*\AC\INetHistory|*.*|RECURSE
FileKey4=%LocalAppData%\Packages\AdobeSystemsIncorporated.AdobeReader_*\AC\Microsoft\CLR_v4.0*|*.log|RECURSE
FileKey5=%LocalAppData%\Packages\AdobeSystemsIncorporated.AdobeReader_*\AC\PRICache|*.*
FileKey7=%LocalAppData%\Packages\AdobeSystemsIncorporated.AdobeReader_*\AC\Temp|*.*
FileKey8=%LocalAppData%\Packages\AdobeSystemsIncorporated.AdobeReader_*\LocalState|*.*|RECURSE
FileKey9=%LocalAppData%\Packages\AdobeSystemsIncorporated.AdobeReader_*\TempState|*.*|RECURSE
RegKey1=HKCU\Software\Classes\Local Settings\Software\Microsoft\Windows\CurrentVersion\AppModel\SystemAppData\AdobeSystemsIncorporated.AdobeReader_ynb6jyjzte8ga\PersistedPickerData\AdobeSystemsIncorporated.AdobeReader_ynb6jyjzte8ga!App\DefaultOpenFileSingle|LastLocation
RegKey2=HKCU\Software\Classes\Local Settings\Software\Microsoft\Windows\CurrentVersion\AppModel\SystemAppData\AdobeSystemsIncorporated.AdobeReader_ynb6jyjzte8ga\PersistedStorageItemTable\MostRecentlyUsed

Link to comment
Share on other sites

Alphabetically? or line length (asc|desc)?

Alphabetic

 

What follows looks like a chaotic jumble caused by each member of a committee putting an entry into a hat,

and then for fairness the chairman was blindfolded as he pulled each suggestion out of the hat. :-

 

FileKey7=%LocalAppData%\Packages\AdobeSystemsIncorporated.AdobeReader_*\AC\Temp|*.*

FileKey5=%LocalAppData%\Packages\AdobeSystemsIncorporated.AdobeReader_*\AC\PRICache|*.*

FileKey9=%LocalAppData%\Packages\AdobeSystemsIncorporated.AdobeReader_*\TempState|*.*|RECURSE

FileKey8=%LocalAppData%\Packages\AdobeSystemsIncorporated.AdobeReader_*\LocalState|*.*|RECURSE

FileKey1=%LocalAppData%\Packages\AdobeSystemsIncorporated.AdobeReader_*\AC\INetCache|*.*|RECURSE

FileKey2=%LocalAppData%\Packages\AdobeSystemsIncorporated.AdobeReader_*\AC\INetCookies|*.*|RECURSE

Link to comment
Share on other sites

  • Moderators

New:

 


[WinX YouTube Downloader*]
LangSecRef=3023
Detect=HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\WinX YouTube Downloader_is1
DetectFile=%ProgramFiles%\Digiarty\WinX_YouTube_Downloader\WinX_YouTube_Downloader.exe
Default=False
FileKey1=%AppData%\Digiarty\WinX YouTube Downloader|*.jpg

 

Edit: I updated the detection by also adding in "Detect="

That way if someone does a custom install not in the default location it can still clean the .jpg thumbnails.

Edited by Andavari
Added Detect=
Link to comment
Share on other sites

  • Moderators

WINSXS contains source files for Windows installations. If you delete one that is later need by Windows to install something, you are in a world of hurt.

In fact, even that isn't the complete truth, they are just 'links' to the physical file which usually live in \windows\system32 (for example) and it you look at each entry in WINSXS they are only a few KB each.

your folder size is probably showing an over-inflated value due to these links being reported twice.

 

think of them as system files needed by the OS - leave them alone.

in the overall scheme of things, they don't use much space. (expect for SSD's maybe)

Backup now & backup often.
It's your digital life - protect it with a backup.
Three things are certain; Birth, Death and loss of data. You control the last.

Link to comment
Share on other sites

In fact, even that isn't the complete truth, they are just 'links' to the physical file which usually live in \windows\system32 (for example) and it you look at each entry in WINSXS they are only a few KB each.

Close, but not quite.

 

Using Defraggler - BUT NOT to defrag anything,

I can Search and specify CMD.EXE in "filename contains:"

and check "Include non-fragmented files"

and it shows me only 2 instances, each of different sizes, one in System32, and one in SysWOW64

It sees none at all in WinSXS because, as you said, WinSXS are only links.

 

Using Windows explorer these two large file are also shown at

C:\Windows\winsxs\amd64_microsoft-windows-commandprompt_31bf3856ad364e35_6.1.7601.17514_none_e932cc2c30fc13b0

and

C:\Windows\winsxs\wow64_microsoft-windows-commandprompt_31bf3856ad364e35_6.1.7601.17514_none_f387767e655cd5ab

and Windows Explorer is fooled into seeing these as being the same sizes as the real things, i.e.

337 KB and 296 KB

 

Using Defraggler and Searching for *.exe takes a couple of seconds.

When I click on the "Path" Tab a couple of times the results are sorted in reverse sequence,

and fourth from the top is vbc.exe which is 1.11 MB (1,169,224 bytes) and is on the path

C:\Windows\winsxs\x86_netfx-vb_compiler_b03f5f7f11d50a3a_6.1.7601.17514_none_144b6bd462e4a41b

 

Searching for vbc.exe Defraggler finds instances at the above, plus 2.25 MB (2,361,160 bytes) on path

C:\Windows\winsxs\amd64_netfx35linq-vb_compiler_orcas_31bf3856ad364e35_6.1.7601.17514_none_f4285a06060032a9

plus 4 more instances of various large sizes under the parent

C:\Windows\Microsoft.NET\Framework\ etc. etc.

 

When I click on Sizes I see that Defraggler finds all 6 items have different sizes ranging from 1 MB to 3 MB

Windows Explorer on the other hand sees 10 such items, 8 of which are duplicates and the other 2 are unique.

The 2 unique files were modified and created on 30/01/2012 and exist only in .NET Framework but not in WinSXS,

the 8 other files all have date stamps of 21/11/2010

 

Conclusion :-

Originally there were 4 off VBC.EXE files of different sizes,

Two of which were scattered across .NET etc, and duplication links planted in WinSXS,

and two of which were scattered across WindSXS and duplication links planted in .NET etc.

Subsequently there were patch updates and SP1 and these added two files that were planted in .NET only,

but for some reason no confusing duplication links to/from WinSXS.

 

FINAL CONCLUSIONS :-

Windows XP was too good and users were able to understand it and use it and become self-supporting experts,

so Microsoft chose to confuse everyone with the needless complication of WinSXS which does nobody any good,

and to carefully hide the truth (from anything but Defraggler) as to which was physical and which was the link,

and just when a user figures out the truth in one instance the next instance is the other way round.

 

The good news is that by 30/01/2012 the developers became so confused they could no longer cope with WinSXS,

hence the latest VBC.EXE files only exist in .NET etc and there are no additional lying deceitful links in WinSXS.

Link to comment
Share on other sites

  • Moderators

So @Alan_B, to answer @vBender's question, would you agree to leave them alone or go for broke at your own peril?

Backup now & backup often.
It's your digital life - protect it with a backup.
Three things are certain; Birth, Death and loss of data. You control the last.

Link to comment
Share on other sites

For every item that Windows Explorer and other "File Finders" can discover in WinSXS :-

 

There is a 50 % chance that deleting that item will actually delete a link and merely increase total free space by a few KB,

(unless that deleting that link also deletes the multi-megabyte target file from System32 or wherever, as happened in the past when reparse points were deleted);

OR there is a 50% chance that you are deleting the real thing and the links in System32, .NET etc. are broken

 

There is a 100% certainty that you either make no space savings at all, or this is another Death of a thousand cuts to Windows.

 

It might be an amusing experiment to totally delete WinSXS and see if you can still boot into Windows and run SFC :o

Link to comment
Share on other sites

  • Moderators
It might be an amusing experiment to totally delete WinSXS and see if you can still boot into Windows and run SFC

please note: management does not endorse this ;) DO, if you really want to, at your OWN RISK (don't come back here crying that now your computer is broken nor crowing that "nothing bad" happened

 

ADVICE FOR USING CCleaner'S REGISTRY INTEGRITY SECTION

DON'T JUST CLEAN EVERYTHING THAT'S CHECKED OFF.

Do your Registry Cleaning in small bits (at the very least Check-mark by Check-mark)

ALWAYS BACKUP THE ENTRY, YOU NEVER KNOW WHAT YOU'LL BREAK IF YOU DON'T.

Support at https://support.ccleaner.com/s/?language=en_US

Pro users file a PRIORITY SUPPORT via email support@ccleaner.com

Link to comment
Share on other sites

Close, but not quite.

 

Using Defraggler - BUT NOT to defrag anything,

I can Search and specify CMD.EXE in "filename contains:"

and check "Include non-fragmented files"

and it shows me only 2 instances, each of different sizes, one in System32, and one in SysWOW64

It sees none at all in WinSXS because, as you said, WinSXS are only links.

 

Using Windows explorer these two large file are also shown at

C:\Windows\winsxs\amd64_microsoft-windows-commandprompt_31bf3856ad364e35_6.1.7601.17514_none_e932cc2c30fc13b0

and

C:\Windows\winsxs\wow64_microsoft-windows-commandprompt_31bf3856ad364e35_6.1.7601.17514_none_f387767e655cd5ab

and Windows Explorer is fooled into seeing these as being the same sizes as the real things, i.e.

337 KB and 296 KB

 

Using Defraggler and Searching for *.exe takes a couple of seconds.

When I click on the "Path" Tab a couple of times the results are sorted in reverse sequence,

and fourth from the top is vbc.exe which is 1.11 MB (1,169,224 bytes) and is on the path

C:\Windows\winsxs\x86_netfx-vb_compiler_b03f5f7f11d50a3a_6.1.7601.17514_none_144b6bd462e4a41b

 

Searching for vbc.exe Defraggler finds instances at the above, plus 2.25 MB (2,361,160 bytes) on path

C:\Windows\winsxs\amd64_netfx35linq-vb_compiler_orcas_31bf3856ad364e35_6.1.7601.17514_none_f4285a06060032a9

plus 4 more instances of various large sizes under the parent

C:\Windows\Microsoft.NET\Framework\ etc. etc.

 

When I click on Sizes I see that Defraggler finds all 6 items have different sizes ranging from 1 MB to 3 MB

Windows Explorer on the other hand sees 10 such items, 8 of which are duplicates and the other 2 are unique.

The 2 unique files were modified and created on 30/01/2012 and exist only in .NET Framework but not in WinSXS,

the 8 other files all have date stamps of 21/11/2010

 

Conclusion :-

Originally there were 4 off VBC.EXE files of different sizes,

Two of which were scattered across .NET etc, and duplication links planted in WinSXS,

and two of which were scattered across WindSXS and duplication links planted in .NET etc.

Subsequently there were patch updates and SP1 and these added two files that were planted in .NET only,

but for some reason no confusing duplication links to/from WinSXS.

 

FINAL CONCLUSIONS :-

Windows XP was too good and users were able to understand it and use it and become self-supporting experts,

so Microsoft chose to confuse everyone with the needless complication of WinSXS which does nobody any good,

and to carefully hide the truth (from anything but Defraggler) as to which was physical and which was the link,

and just when a user figures out the truth in one instance the next instance is the other way round.

 

The good news is that by 30/01/2012 the developers became so confused they could no longer cope with WinSXS,

hence the latest VBC.EXE files only exist in .NET etc and there are no additional lying deceitful links in WinSXS.

 

Is it just me experiencing serious deja vu here? I'm sure we had this exact conversation just a few weeks ago :huh:

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.