Process Tamer not taming processes under Win10-64

[IainB]

Thought I should report this.
I had previously reported on problems under Win8.1-64 PRO.

[Shades]

The Bingbar might be a process that is started by an background service and as such can be immediately restarted after an instance has been shut down. Any depending process will be restarted as well. When you look with a tool like Process Explorer (part of the SysInternals suite), you will see a different PID number next to any currently active process. Did you verify that the PID number for that particular process remained the same? If that is the case, then ProcessTamer didn't kill the process. But if the PID number changed, the process was immediately restarted after being terminated.

The GoogleCrashHandler.exe and GoogleCrashHandler64.exe are part of the Google process that always remain running in Windows after you installed any Google product on your computer. This software will be immediately restarted after termination. Another part of the SysInternals suite is called AutoRuns, and with that you can control which items/processes/services start at boot time. While this software works fine with other products, disabling or even removing any entry related to a Google product will only result in a double or renewed entry. In this sense, Google products act like a virus would. Which is the reason why I won't install any version of Chrome on any of my computers. This obnoxious behavior actually inspired me to look for portable software packages instead of installers.

Being able to change of the priority of a process depends on how it is started. If a process is started ('Run as Administrator') in a user account and ProcessTamer is started normally in this user account, chances are that Windows won't allow ProcessTamer to alter the priority of the process. While this might work in Windows Vista/Win7/Win2008, don't expect this to work in Windows 8/8.1/Win2012 (i have found this out the hard way). The security model of those operating systems was much more tightened.

Now with the new Windows 10 and soon to be released Win2016, expect even more tightening in the security model Windows applies for running processes. Each new iteration gives you less control and will behave more and more like iOS and OSX already do. At least, that is how the Windows experience starts to look like to me. Just different colors and style of icons, but similar levels of control (or lack thereof).

Enough ranting, holding ProcessTamer responsible for this kind of misbehaving software is a bit harsh in my opinion.

[IainB]

@Shades: Ah, thanks for that input, though I suspect that you might have been rather jumping to conclusions.
As is my wont, I've been quite thorough in checking the consistent repeatability of the things I reported. I assure you that I was not intending "...holding ProcessTamer responsible for this kind of misbehaving software", since none of the software is "misbehaving" - or, at least, not as far as I am aware.

It's very curious. I wondered whether the newer OS(es) had inadvertently caused some processes to be somehow partially transparent to PT - not totally transparent. It's as though PT can't get a handle on some processes. They are sort of "untouchables".
In testing (which I still have running), I have found that PT correctly kills those other Google processes you mention, and shuts them down again if/when they are auto-restarted a short while later. No problem. PT displays an alert each time it shuts down or modifies a process. Tedious, but at least it tells me what PT is doing, and when.
The first two examples I have given are simply that - two examples of a failure to "kill" by PT. PT does not display an alert that either process has been killed. Neither of them flicker out and then return in ProcessHacker, and the PID remains the same, so it's definitely not the case that they are being killed and then restarted without my realising it.
In the case of SeaPort.exe, for years PT used to successfully kill SeaPort.exe, and it would stay shut down (not restart), but no more.

The third example - the failure to modify the xplorer² process - is odd, as PT displays the process in its list of processes, showing its Priority as "Normal", and (amusingly) next to it the Explicit Rule "Force High". PT does not display an alert that the xplorer² process priority has been changed. I have tried, and PT can't seem to kill that process either.

By trial and error, I have discovered a couple of other "untouchables" - processes that I would normally not wish to mess with, but which, when I tried, PT seems unable to change or kill - and it so far seems to be a consistent and repeatable rule that if PT can't kill a process, then neither can it change that process' priority, and vice versa.
 
Maybe there is some simple explanation that I am overlooking here, but, as I say, it's very curious.