bimmerdriver

Since I also use other nirsoft applications, I tried regscanner. It works really well. Thanks for the suggestion.

I can confirm that skip uac stayed working through a major insider update since I did the deinstall and reinstall. It's good to have this issue gone.

As of creators update, this seems to be fixed, although you may need to deinstall and reinstall ccleaner.

There was another insider update and it's still working.

I deinstalled ccleaner and reinstalled it, enabled the setting to skip the uac warning, then logged out and back. There was no warning. I hope it stays working. If so, for some reason, it seems necessary to deinstall and reinstall the software for the setting to skip the uac warning to work.

Among the computers I'm running windows 10 and ccleaner on, some are updated post anniversary / pre creators, one is post creators and one is an insider fast ring (post creators). ccleaner has a uac warning on all of them. I've tried deinstalling ccleaner and even searching through the registry to remove any left-over keys after deinstalling it, then reinstalling it. It makes no difference. Every time I login, I get the warning. I've attached the relevant screen captures.

I don't disagree that UAC hasn't been one of Microsoft's finer moments, but it serves a purpose and disabling it completely defeats that purpose. Users should not have to disable a security feature because of a bug in Piriform's software. Piriform, if you're listening, fix the d*amn bug!

This has not always been a problem. As far as I can remember, it started with the anniversary update. I have 6 windows 10 computers, running various versions of windows 10 and it effects all users on all of the computers. The association of this issue with $arg0 came from this website. I'm not in a position to prove or disprove it. However, as I pointed out, if $arg0 really is the problem, changing the task type to windows 7 should not fix the problem, which is why I question that it does fix the problem. There is nothing unique or special about my computers. I've tried completely deinstalling ccleaner including manually deleting any associated keys from the registry and the problem will not stay away. As I said, if $arg0 has gone away, piriform needs to use another method for passing arguments at login. When I removed $arg0 from the task, there was no uac error, so perhaps the uac error is what windows 10 generates if it's passed arguments using $arg0. Maybe it's an incorrectly coded error notification from windows. Who knows?

First, I'm not the developer. However, I used to be a software developer. If Piriform wants to develop software for windows 10, they need to use available mechanisms. If arg0 is no longer supported, unless microsoft changes their mind, piriform continuing to use it won't make it work. Ccleaner isn't going to wear down windows 10. Doing the same thing over and over expecting a different result is the definition of insanity. Like it or not, Microsoft sets the rules. Not supporting arg0 is not a windows 10 bug. It's a feature. The fact that ccleaner is trying to use a feature that's no longer supported makes this a ccleaner bug. Second, I'm not the only person for which the supposed fix doesn't work. As you sure you haven't simply disabled UAC for all applications so it appears to work? I have several different computers running windows 10. It happens on all of them. Third, it makes no sense that using the windows 7 format should work, because it also uses arg0. If windows 10 doesn't support arg0, there is no reason for the windows 7 format to work. Fourth, as I said, other applications start up upon login and don't generate any UAC warning. None of them use arg0. The tasks for other applications pass parameters in other formats, such as /c, /ua /installsource scheduler and sync. Pifiform needs to use a supported mechanism to pass the parameter, like other applications. Fifth, if I remove the arg0 parameter from the windows 10 task for ccleaner, it starts without generating a uac warning. It just doesn't start in the right mode. Presumably, if the parameter is passed using a supported mechanism, ccleaner will start in the correct mode without generating a UAC warning.

Updating this thread. My computer is on the latest insider release, post creators update, build 16184 and ccleaner skip uac is still not working. It's probably reasonable to think that if Microsoft has not restored the $(Arg0) function by now, they have no intention of doing so. In that case, it's time for Piriform to fix this annoying bug.

Updating this thread. My computer is on the latest insider release, post creators update, build 16184 and ccleaner skip uac is still not working. It's probably reasonable to think that if Microsoft has not restored the $(Arg0) function by now, they have no intention of doing so. In that case, it's time for Piriform to fix this annoying bug.

I did reboot after uninstalling, then reinstalled. It didn't fix the problem, so I went to the extra step of uninstalling, searching the registry and removing all ccleaner keys, then rebooting, then reinstalling. It made no difference. I have two computers running windows 10 and both have this problem, as of today, both are running the latest "creators" update. I don't see how it's not a bug. ccleaner is trying to use $(Arg0) for windows 10 and windows 10 no longer supports it. piriform needs to make a new method of passing arguments not using $(Arg0) like every other app.

I've found that many applications don't do a good job of cleaning up after themselves when they are deinstalled. I've often found many registry entries left over. It would be nice for ccleaner to search the registry looking for keys containing a particular keyword so they can be removed.

Another vote for this.

I agree that the pinned solution doesn't work. If you select the windows 7 version, ccleaner still tries to use $(Arg0). I edited the ccleaner task and removed $(Arg0) to see what would happen. ccleaner was started at login with no UAC error, but it wasn't in the monitoring mode. So the problem isn't that it's using the windows 10 task type, it's $(Arg0). Using the windows 7 task type doesn't fix anything, because it uses $(Arg0), which is fine, since windows 7 supports it. As I posted in the ccleaner forum, this is a piriform bug and it's not going to get fixed by piriform blaming it on Microsoft for deprecating $(Arg0). Microsoft in their infinite wisdom or lack thereof changed windows 10. If Windows 10 no longer supports $(Arg0), the approach being taken by piriform is broken. It's a bug. Also, none of other the other tasks on my computer have this problem and not surprisingly, they don't use $(Arg0). Unless Piriform has inside knowledge that Microsoft is going to restore $(Arg0) the way it was, for ccleaner to set up a task in "windows 10" mode passing $(Arg0) is broken and will never work and therefore piriform's "windows 10" mode needs to be fixed. Dropbox and google pass arguments to tasks, just not using $(Arg0). No other tasks have this problem. Piriform needs to modify ccleaner so it will pass arguments using another method, like other tasks do. How is this NOT piriform's problem? Piriform, please fix this problem. It annoys the heck out of me and the other people who use the computers I installed ccleaner on. This bug causes people to think ccleaner is annoying, even to the point of uninstalling it. It's not reasonable to leave this bug unfixed.