bgavin

I solved my issue by having my script issue an ICACLS command to C:\Program Files\Portable\ icacls "C:\Program Files\Portable" /grant *S-1-1-0:(OI)(CI)F /T /Q // SID is SECURITY_WORLD_SID_AUTHORITY (all users) I am the only one who uses this directory, and the subs beneath it for my various utilities.

I install it on my workstation for my own use because I don't want the installed version with Optimizer, etc. I have no desire to plug in a USB stick when I want to run it. I will move it to User\Public instead and avoid the crash. You still have a bug with a nasty crash from an unhandled exception that is permissions-related.

Thanks so much for the wealth of information as a work-around. I will put it to good use. As to the developers, they have a nasty crash from an unhandled exception. Good programming handles the exceptions as well as the code that works properly. Just because the developer didn't intend on something doesn't give him license to ignore it when it crashes. Not my problem though. You mention Pit99 has a thread that is also permissions related. Something changed from v5.81 to v6.x regarding permissions. Where there is smoke.. there is usually fire. Long experience has taught me that ignoring recreateable bugs will always come back to bite me in the ass.

KB447419 is already installed. Win7 Pro is 64-bit and fully patched. v6.05 "Run as Administrator" does not crash. I don't have access to previous v6 versions. The Administrators Group has full control of the parent directory and this user account is a member. CACLS confirms the same. It is a permissions thing. My comment still stands about crashing instead of providing a graceful unhandled exception exit.

Where I want to run CCleaner is irrelevant. My comment is entirely about "something changed" in the permissions requirement of the v6 release. v5.91 and older runs just fine in C:\ProgramFiles\Portable\CCleaner along with several others. I keep several user accounts on my primary workstation, and C:\ProgramFiles\Portable\CCleaner presents a single instance to each account. Installing in C:\Users\... is clumsy, and tied to a specific user. Yes, I could install it to other than C:\ProgramFiles, and will probably have to do this as a work-around. The current v6 version goes to an instant App Crash... very ungraceful handling of an unexpected exception. If the developer is going to change something in the permission environment, he should also update his exception handler for a more graceful exit. I'm old school, and fed up with "installed" code that inserts junk into the registry and directories, never to be removed by "uninstall." Most developers have not got a clue what the word "uninstall" means... because they leave droppings in the registry and various directories. Some of these are damn hard to get rid of, especially if installed in a user profile that has since be deleted. CCleaner Portable still has droppings in the registry, but does not hook nor insert into the DLL chain, or other potential problems. I so appreciate it is a standalone product.

I extract CCleaner portable to a tools directory, then copy the extracted structure it to C:\Program Files\Portable\CCleaner The v5.91 version runs fine here, but 6.05 has an App crash with both x86 and x64 versions at launch. It appears CCleaner 6.05 is doing something new that requires Administrator privileges in this directory. This is easily recreated by extracting the ZIP into the above directory. I have backed down to v5.91 which operates without crashing. Problem signature: Problem Event Name: APPCRASH Application Name: CCleaner64.exe Application Version: 6.5.0.10110 Application Timestamp: 63512f34 Fault Module Name: CCleaner64.exe Fault Module Version: 6.5.0.10110 Fault Module Timestamp: 63512f34 Exception Code: 40000015 Exception Offset: 0000000000e6131b OS Version: 6.1.7601.2.1.0.256.48 Locale ID: 1033 Additional Information 1: ced2 Additional Information 2: ced2b0fe725a541c6a31519fe1f18871 Additional Information 3: 75ed Additional Information 4: 75edcc7c50f398fec1f46bea8ca1d547

"The sticking point is the structural change required for Performance Optimizer although Performance Optimizer would not work properly when the software is being used in a genuinely portable manner. " This means Portable development is stalled because these features are taking precedence. When the development is stalled, so are fixes for newly discovered bugs. I don't have a problem at all, when the app is stable and bug free. It is the rare app indeed, that remains free of newly discovered bugs. My lengthy experience in the software industry shows the developers move on to the newest, latest, greatest and don't fix the old bugs. "Upgrade to the latest" is the mantra. I remain hopeful that Portable won't stagnate and die because it doesn't work with all the latest bells and whistles. Some of use prefer a reliable rope and tire in lieu of a feature-laden gilded swing set.

This sounds to me like Portable is going to die, the same way Speccy portable did. Simple, functional and straight forward apps all seem to die on the deathbed of More Features. A pity. I don't need ever more features. What I do need, is the bug fixes they always find in the basic functions.

Interesting... all those registry droppings resulted because the EXE was not finding "portable.dat" which was not in the executing directory. Thanks for the pointer... I will have to make sure I don't have a scheduled task created as you show above. My installation script creates C:\Program Files\Portable\CCleaner This path is universal for both X86 and X64 systems. Depending on PROCESSOR_ARCHITECTURE being AMD64 or not, determines which of the ZIP source directories I copy. Once the EXE is in the above location, I create a shortcut to that EXE and add it to the All Users Start Menu I found the change in ZIP structure when my script threw an error while validating the (changed) location of the zip contents. Thanks again for the great tutorial. Much appreciated.

Your suggestion above is the not directory structure in the ZIP file. Unzipping to a parent directory, this top level directory holds the portable.dat file, and the child \x64, \x86 and \lang directories. If one assumes to run either X86 or X64 from the unzipped structure, one has to assume the EXE will search for ..\ for portable.dat and the lang directory. If the developer intended for the user to tweak the unzipped directory structure, I would be surprised. As this would require the end user be smart enough to shift the directory structure around to something different than when it unzipped. As a developer, I would be searching in the startup directory first, then ..\ for portable.dat and any required ..\lang files.

Portable does indeed create registry entries. HKEY_CURRENT_USER\Software\Piriform\CCleaner HKEY_LOCAL_MACHINE\SOFTWARE\Piriform\CCleaner I deleted both keys previously. Then I ran Portable 5.92 with a Clean and Registry scan. After doing so, both the above keys are again created. 42 values are created below as (Cfg)xxxx all are REG_SZ type. These appear to be the same found in the portable INI.

.INI in the portable directory shows UpdateCheck=0 As to registry... nearly every programmer in the world fails to understand the true meaning of "uninstall", because they always leave registry droppings behind. CCleaner is no exception, apparently. A long time ago, I used to run the installed version, hence the registry entries. When I moved to the Portable version, I *uninstalled* the installed version. I did not check for registry droppings, of which there is a full load, similar to the portable INI file. I can certainly delete the entire registry structure, as it appears to be tied to only a single key, as shown in my post above. Found more registry entries: HKEY_LOCAL_MACHINE\SOFTWARE\Piriform

So far, it appears the Portable is going to update itself if the update boxes are checked or not checked. My process: Clear the destination folder. Unzip to the destination folder. Check destination for update files, none found. Launch CC portable. Settings: uncheck all update boxes Run a CLEAN function. I then notice version has changed to v6, and update files now in the destination directory. Registry key: HKEY_CURRENT_USER\Software\Piriform\CCleaner UpdateCheck = 0 UpdateKey = SZ for date string

Thanks for the pointer to the old files. I normally keep all the prior versions in a ..\DOWNLEVEL directory on my main service drive. Over the years, I have learned the hard way to do this... because so many downlevel versions are removed. I install Portable into C:\Program Files\Portable\CCleaner on the client machine, then run from there. This is a fixed location, so the INI files for that client are always current. The parent directory name is compatible with both x86 and x64 architectures. My script determines which platform CCxx.exe is required and installs it and it support files. WinXP clients require the sunset version which is a separate source from the current Portable.

Yep. This is what it is doing. Check for Updates is checked by default. The first time an action is performed, such as a Clean, it updates to v6, brings in CCUpdate.exe and the others. Q: is there a registry key, or ?? I can incorporate in my script to disable automatic update, and uncheck all the options to delete cookies? The newer/newest CC is failing to display over remote access to a client's server, which is what prompted this bug report. The latest Quickbooks Hub utility is also failing the same way, under the latest Win10 build. I will have to chase this down further. I save all the old CC portable versions, so it will be easy to downgrade a version or two to decide if this is version specific. Or (more likely) yet another Windows 10 "feature".

Yes, I am certain it did not run the regular version. I do not have any CC installed in my list of installed software. If it had run the regular installer, then v6 would be showing as an installed program. It is not. This is easy to duplicate. Take a regular machine, or a VM, that does not have CC installed. Download the portable zip, extract to any folder. Run the CC x64 executable from the extracted files. Note the version number. Run the same x64 executable a 2nd time, note the file dates and version change. Examine the installed programs in the Control Panel, you will not see a regular installed CC. Note: there is an architecture change in this version. The previous portable ZIP had the EXE in the top folder. The new portable zip, has the EXE in either the x86 or x64 folder, along with multiple new files. I normally install the portable version into C:\ProgramFiles\Portable\CCleaner with a script. The latest version failed, due to the changed files in the new portable directory structure. Something changed in the new version.

I grabbed the portable zip, and expanded it to a drive. In the x64 directory, I launched ccleaner64.exe On the first launch, it displayed v 5.92 The file system dates are April 7. 2022 at 04:42am The 64 bit version displays "v5.92.9652" I closed it, and launched a second time. This time, it asks several "do you want to run" questions. When CC finally comes up, it is now v6.00.9727 Files are dated 5/11/2022 at 01:16 am. Options | Keep Updated Automatically is checked.

This portable version hangs under Windows 10,0.19044.1706 It requires closing the process by Task Manager, as it won't close from a taskbar icon. This is a Win10 problem, as the bug is not present in Win7. The file structure of the ZIP has changed with this version. I create a directory structure: C:\Program Files\Portable\CCleaner for these files. It hangs run from here under the Administrator account. The failure is same when the zip is extracted to the local user profile, or from a network directory. It creates an Event ID 1002 Task Cetegory (101). All prior versions of Portable run correctly on this machine. This new version, with the changed ZIP file structure is crashing.