Jump to content
CCleaner Community Forums
Winapp2.ini

Winapp2.ini additions

Recommended Posts

This will take care of many traces from things like flash, but websites can see your IP and MAC addresses, so they'll still know it's you ;)

Share this post


Link to post
Share on other sites

so what does this do exactly?

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

Share this post


Link to post
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! :)

Share this post


Link to post
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*]

Share this post


Link to post
Share on other sites

Whoops. I'll work that out.

 

What actually happens if an entry is loaded twice, does it show twice?

Share this post


Link to post
Share on other sites

What actually happens if an entry is loaded twice, does it show twice?

 

Sorry, I didn't check that. I found the doubled entry while scrolling through winapp2.ini.

Share this post


Link to post
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

Share this post


Link to post
Share on other sites

Thanks.

 

By the way, cosmetically speaking, which would you folks prefer for filekey/regkey ordering?

 

Alphabetically? or line length (asc|desc)?

 

It'd be totally cosmetic and probably have no effect on the file itself other than making it look a bit nicer.

Share this post


Link to post
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

Share this post


Link to post
Share on other sites

True enough. I'll work on that for the next release.

 

Edit: for all entries, not just the windows 8 ones.

 

Double edit:

 

FileKey5=%Documents%\My RoboForm Data\*.*|mru.rfo;cache.rfo

 

 

Can someone confirm that should be \*.*| and not \*|

Share this post


Link to post
Share on other sites

FileKey5=%Documents%\My RoboForm Data\*.*|mru.rfo;cache.rfo

 

Can someone confirm that should be \*.*| and not \*|

Both work.

Share this post


Link to post
Share on other sites

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=

Share this post


Link to post
Share on other sites

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)

Share this post


Link to post
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.

Share this post


Link to post
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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
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:

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...