Winapp2.ini
-
Posts
6,470 -
Joined
-
Last visited
Posts posted by Winapp2.ini
-
-
The LevelDB Logs generated by Google Chrome extensions are not logs in the conventional sense we usually approach with intention to delete. They hold buffer data for the LevelDB storage.
-
6 hours ago, SMalik said:
New Entry
https://www.itprotoday.com/windows-server/microsoft-details-sleep-study-tool-windows
[SleepStudy Logs *]
LangSecRef=3025
Detect=HKCU\Software\Microsoft\Windows
Default=False
FileKey1=%WinDir%\System32\SleepStudy\ScreenOn|*.etl
FileKey2=%WinDir%\System32\SleepStudy|*.etlI think these FileKeys should be folded into either Windows Logs * or Windows Subsystems * rather than have their own entry, good find
-
A new version of winapp2ool.exe is available for testing (not yet pushed to master)
Should be of particular interest to WindowsXP users, as there is now a version that should work on your system. Please let me know if anything jumps out as super broken.
-
On 10/30/2018 at 09:47, dvdbane said:
got this error and winapp2ool crash when running offline while trying to setup winapp2.ini on my friend laptop
no error when running online
test function merge and trim, no problem, didn't test other features
does this cause by not using dotnet 4.6 like issue #251 on github?
win 7 sp1, dotnet 4.5.2
This error wasn't happening in my development environment (probably due to the nature of debugging applications) but it should be fixed in the next winapp2ool update. The application is intended to be usable when offline (with the exception of online functions)
If using .NET 4.5.2 you should also see a message on the menu informing you that the tool requires .NET 4.6 but 4.6 is only required to use TLS 1.2 for downloading the executable. Everything else should work as expected -
I think items associated with VirtualStore locations are related to how Windows handles sandboxing / security when the UAC is enabled.
-
8 hours ago, SMalik said:
Not all traces are being wiped.
Are the files process locked?
-
3 hours ago, JDPower said:
So revolutionary. I've had my Firefox set up to do this for years - tabs restored from last session and FF set to run at startup
Chrome has a similar feature that I've noticed but never seen discussed, so does Windows Explorer!
I think this is something Microsoft is trying to take on as a UX problem (ie. unexpected restarts interrupt a user's workflow in a very destructive way)
Timeline on Windows 10 and the upcoming (or released? I'm not sure) "Sets" feature I've seen talked about seem to be about remembering the context of your open applications and restoring them when appropriate.
-
At this point yes, the features are mostly in their final state under the new menu system. I'll be working on creating documentation for it all soon.
14 hours ago, siliconman01 said:Is the format for 0.85beta for the features included at this point pretty much as you expect to keep them? The reason for my question is that I would like to generate a "How to use" procedure for a few "not so computer savvy" friends and relatives that I help with their computers.
They are currently using the pre-Winapp2ool tools to trim their Winapp2.ini. They only use Trim and the CCinidebug tools because I do the other "stuff" prior to sending them the latest Winapp2.ini each time a new version of CCleaner is released.
TIA for your feedback.
On a related note, I have intention to create likely one more module that executes combinations of the other modules tasks, so simplify the tool further.
-
Winapp2ool has been (officially) updated to v0.85beta, existing previous versions should inform users of this.
-
I created a "redux" version of Trim called TrimXP which targets .NET Framework 4: https://github.com/MoscaDotTo/Winapp2/tree/master/Tools/TrimXP
This should be useful to anyone on WindowsXP who cannot otherwise run winapp2ool due to the .NET 4.6 Requirement
The only concern I have is that I have never tested environment variable expanding on WindowsXP and don't know how/if some will work.
-
On 5/25/2018 at 01:34, siliconman01 said:
For some reason, the TRIM function of winapp2ool.exe (V0.8.0.0) does not recognize the DetectFile shown below for Chrome and it trims these all out.
DetectFile2=%LocalAppData%\Google\Chrome*
If I change this to DetectFile2=%LocalAppData%\Google\Chrome, then they are not TRIMMED out.
I wonder if CCleaner is recognizing %LocalAppData%\Google\Chrome* where it is used in FileKey and ExcludeKey. ???
A build of winapp2ool.exe with this fixed is available: https://github.com/MoscaDotTo/Winapp2/pull/245
It's not yet on the master as I've made significant changes to the code and want to make sure everything is still functional before pushing. Everything in my tests seemed OK though
-
12 hours ago, siliconman01 said:
For some reason, the TRIM function of winapp2ool.exe (V0.8.0.0) does not recognize the DetectFile shown below for Chrome and it trims these all out.
DetectFile2=%LocalAppData%\Google\Chrome*
If I change this to DetectFile2=%LocalAppData%\Google\Chrome, then they are not TRIMMED out.
I wonder if CCleaner is recognizing %LocalAppData%\Google\Chrome* where it is used in FileKey and ExcludeKey. ???
This is a bug (oversight regarding expanding wildcards) in Trim and will be fixed in an upcoming major update to the tool
Thanks for pointing this out
-
I think it'd be a better user experience to use a tool like Everything to do broad recursive searches for filetypes
-
19 hours ago, ROCKNROLL said:
Actually, I would much rather starting moving things over to GitHub. Once Winap2ool comes out of beta, I will be working on making a better readme and documentation over at GitHub. Eventually, we will probably end up closing the Winapp2 website as it doesn't have much purpose anymore, but this hasn't been discussed, yet.
I don't mind keeping this thread open. Perhaps a bit of cleaning of this thread would coming in handy (we are almost at 300 posts). Maybe people will be nice enough to specify if there contributions belong to Winapp2 or Winapp3 for the future.
300 posts? There's over 7000!
(but I suppose you probably meant pages)
I don't think the thread needs cleaning. That's a lot of work for moderators and now that winapp2 itself is on GitHub it's a lot easier to track which changes actually make it into the file (when I was maintaining it alone and by hand, any changes I missed would be lost to the ages unless someone specifically audited for those changes and pointed out that I'd missed them).
Overall I think that it'd be fitting for winapp3 contributions to be kept exclusively on GitHub. This is the winapp2 thread, and I think it'd be less confusing for everyone if it stayed that way.
-
I don't think winapp3 is substantive enough yet to warrant its own thread or really even much discussion on this one besides update notifications. Any discussion about it is likely best kept to GitHub for the sake of keeping this thread on topic for now.
-
10 hours ago, siliconman01 said:
0.85b is showing 3 duplicate errors when executing WinAppdebug. These are not detected with 0.85
This is the intended behavior. I had been working on finding unneeded parameterizations (eg log*.txt;log.txt -> log.txt is not needed because log*.txt covers it) but I didn't complete that work yet so I had intended to disable it. In the meanwhile, any wholly duplicate parameters should be caught properly by WinappDebug. Anything with wildcards is hit/miss (mostly miss) still.
It should be noted that those errors are actually accurate in your output
FileKey1=%CommonAppData%\CanonBJ\IJPrinter\CNMWindows|drvlog*;drvlog*.*;plmlog*.*;plmlog.*|RECURSE
between plmlog*.* and plmlog.*, only plmlog*.* is needed -
I have a pending update for winapp2ool that could use some testing
here's the PR that lists some of the changes: https://github.com/MoscaDotTo/Winapp2/pull/245
You can get the 0.85b executable here: https://github.com/MoscaDotTo/Winapp2/blob/591c4da686f5c9097a289d0a64389f2133c4ff65/Tools/beta/winapp2ool.exe
Here's a photo showing some of the menu changes that have been put into place
-
On 3/23/2018 at 11:15, Winapp2.ini said:
https://github.com/MoscaDotTo/Winapp2/issues/226#issuecomment-376043221
I updated this post with a small proof of concept tool. If anyone would be interested in maintaining a languages.ini meta file please let me know.
-
On 3/23/2018 at 11:15, Winapp2.ini said:
https://github.com/MoscaDotTo/Winapp2/issues/226#issuecomment-376043221
I updated this post with a small proof of concept tool. If anyone would be interested in maintaining a languages.ini meta file please let me know.
-
-
winapp2ool.exe has been updated
Something not listed in the changes on the commit (pasted below) is that the application should no longer crash when you hand it an ini with no ; version string in it.
I posted about the command line arguments here: https://github.com/MoscaDotTo/Winapp2/issues/200
New: Merge Modes - Merge now has 2 behaviors for dealing with duplicate section names in the two ini files it's merging. The default is Replace & Add, which will replace any sections in the first ini with the section of the same name from the second ini. The other mode will remove any sections with the same names. Enjoy! New: Preliminary support for command line arguments. I'll post a list of these somewhere that isn't this commit message soon. Added basic support for loading winapp2ool with arguments to automate certain tasks. This feature is not fool proof yet (ie. if you try to break it, it will probably break) and for lacking of testing, not necessarily use proof yet either. For this functionality to work, most of the initialization for the modules was rewritten, so most of my testing so far has been to make sure the modules still work for testing the automation (though if the module works then in theory handing it valid command line args should work just as well) CCiniDebug was rewritten to a degree. The prompt to save ccleaner.ini has been removed, and it instead automatically saves its changes back to ccleaner.ini. The prompt to save diff.txt has been removed. It is now available as a menu level toggle instead. [/spoiler]
-
On 3/15/2018 at 01:21, siliconman01 said:
Merge error in Winapp2ool.exe
Attached is a pic that shows that the Merge process in Winapp2ool.exe is clipping off lines at the end of the Merge txt. This is 100% repeatable on my Windows 10x64 Pro systems.
Merge has had its underlying behaviors changed since you posted this (namely how it handles sections with duplicate names between ini files) so I'll have to ask that you test with the newest build when its posted (hopefully tonight!) and see if this issue persists!
-
11 hours ago, siliconman01 said:
This applies to Windows 10x64 Pro Insider Build 17115.1, V1803 and the latest winapp2ool (Run as Administrator). When I attempt to MERGE my custom.ini with winapp2.ini, I get an exception error. I have attached the Event Viewer errors. 4.7.1 .NET Framework is installed.
I think I have an idea of the problem here and have a fix ready. Does your custom.ini have a "; version " string? or any ini comments (lines that start with ; ) at all? If not, try adding one and see if it works. I found a spot in the winapp2file constructor where an exception would occur if handed an inifile object with no comments. If that's the problem, the next build will fix it.
-
winapp2ool has been updated, comes with some neat lil tidbits
user facing changes: new: merge module for removed entries.ini and custom.ini new: autocorrect feature in WinappDebug new: download & trim the latest winapp2.ini new: diff local winapp2.ini against online versions new: download removed entries.ini changed: menu layouts
It also now requires .NET Framework 4.6 which I think means Windows XP will no longer be supported. This is because of a TLS change on GitHub's end that .NET Framework 4.5 alone didn't support.
They are currently using the pre-Winapp2ool tools to trim their Winapp2.ini. They only use Trim and the CCinidebug tools because I do the other "stuff" prior to sending them the latest Winapp2.ini each time a new version of CCleaner is released.
Winapp2.ini additions
in CCleaner
Posted
A new winapp2ool for your consideration: https://github.com/MoscaDotTo/Winapp2/pull/318/commits/976dd4c0885ba3d47e04330b062956dc2e8f5e75