dencorso

But now we know SystemSettings.exe is being started by the ApplicationFrameHost.exe, right? So, whatever is happening under the covers, must be acting on the ApplicationFrameHost.exe...

And... before you do that, since you run it with the UAC turned off, I'd guess you may rename a system file without triggering its instant replacement, right? If so, just rename it to SystemSittings.exe, and let's see whether an error gets thrown, and if so, which process throws it. Is that feasible?

Has a "Cone of Silence" actually been invented, at long last? So they say: Muzo. I do doubt it but, then again, I'm quite pessimist about gadgets like that... What seems too good to be true, usually actually isn't true, you all know.

In your opinion.

@NoelC: Launch Process Hacker via the Startup folder (or an equivalent means) and save a process list just after boot. Wait for the debug console window to open for ApplicationFrameHost.exe and, before dismissing it, save another process list. Compare both lists. What's different? Maybe we can learn something from this exercise, besides what you've already found out...

Since now is late 2016, that means just half again a year hence, by which time I doubt "a lot less" might be more than half the current users... and, if so, XP shall still command about 5% of the desktop market share, and that's actually more than twice the desktop market share linux ever has had, and threfore it still ought to be quite far from a trifle.

Google just wants to ensure Chrome on XP is killed well dead...

True. But that's beside the point, here, because NT-OSes are modular OSes by nature. So they may create one catalog. One single .inf, too. And obfuscate some more. But, at the end of the day, NT-OS files are just modules. And, hence, whatever unwanted payback *is* a file (or a bunch of files) which, either have a previous version that can be rolled back to, or are not previously part of the OS, being thus, by nature, removable. In other words, when one that hates olives but cannot order them out of his/her dish, one may always pick 'em out, by hand, after being served, now, ain't it so?

Update rollups are no more than a bag of strung-together updates... I bet some tool to analyse them is on the verge of appearing. There's enough competent people around annoyed by that and... What one can obfuscate, another can unveil, isn't it?

So you've activated it and it's now working, or did it refuse to acknowledge activation?

Well, I'll give one suggestion that actually *is* part of the usual: grab the latest standalone uninstaller and run it. Reboot. Then reinstall Flash plugin v. 23.0.0.162 on 45.3.0 ESR once again. It may work if something went wrong silently during the upgrade from v. 22.0.0.209...

I'm not saying you should stop updating. You can activate the service manually before updating, but keep it disabled most of the time.

Kill it, then set it to disabled. Whenever you decide to visit Win Update (usually after the patch tuesday) you may then start it manually, just before doing so. And it'll return to disabled after a reboot. You've got no reason to keep it active all the time, now, do you?

If the tree forms, the tyre drops and swings and the clouds move, Flash is working all right. Now, their version detectors are high on something...

There's also svchost viewer, just for that... albeit I don't know whether it still works on 10... but that should be easy to test, because it's standalone.

@sdfox7 and @mixit: I think this movie is the most reliable test to ascertain whether Flash is working (and the link itself is useful) Try it with Flash plugin v. 23.0.0.162 on 45.3.0 ESR and report, please. The standard testers seem to have been messed up on purpose by Adobe (they refuse IE8/9, for instance), however, when it actually loads, the best official tester is still this one. Does it still work with Flash plugin v. 23.0.0.162 on 45.3.0 ESR?

48.0.2 is *the* currently stable version of FF. Mozilla didn't release any news regarding their XP support in recent times.

Thanks, @5eraph! You do rock! It turns out what stopped working with IE8 (even if spoofed as IE9) is this test page.

I confirm @bluebolt's finding: he new pepperflash 23.0.0.162 does not work with Chrome 49.0.2623.112 m !!! Keep on pepperflash 22.0.0.209. That one still works. BTW... Is the Active-X flash v. 23.0.0.162 actually working with IE8?

Try amazon.co.uk...

Not really. I use either Adobe reader 8.1.3 or 9.5.5 in all my machines (even on win 7 sp1 ultimate x64) and never actually needed anything newer, up to now. But since that can change with passing time, it's good to know both X and XI still do work with XP, even if after complaining some.

Yeah, well... Picture on your mind how miserable a smart fridge might make your life: You get home tired and find out there's no cold beer because the fridge got *offended* at something you did or told it. Or worse... at something you failed to do or say it, like, for instance, "Good morning, Your Coldness, how are you today?"... No. Definitely it's too much, nobody deserves that, ever!

You probably can... whether it'll still be in working order is another more difficult question to answer, however...

You're not alone, my friend... I believe the name for it is material's fatigue (although MD's may disagree...).

It's no guess anymore, but fact. Of course we're talking about processors Intel from Jan 2006 or newer. Later Addition: It turns out that the 1st Intel processor to support PREFETCHW was Cedar Mill, the 65 nM final revision of the Pentium 4 released on January 5, 2006. And it seems that the 1st AMDs to support CMPXCHG16B were the Bulldozers, from late 2011!!! Sysinternals' CoreInfo is the right tool to test whether a machine has those requirements or not. NB: Care when interpreting CoreInfo's results: in them a "*" means "yes" and a "-" means "no", but all the features it tests are alway listed. So, the excerpt below means "YES Supports CMPXCHG16B and NO Support for PREFETCHW": ... CX16 * Supports CMPXCHG16B instruction ... PREFETCHW - Supports PREFETCHW instruction ...