![]() ![]() The tests were performed on a 2019 16” MacBook Pro with a Core i9 processor and 16GB of RAM. This was the main question I set out to answer during my tests. Is the Google Chrome updater actually the cause of this WindowServer high CPU usage that people are seeing? Note that this basic research is by no means confirmation that this piece of software doesn’t do anything potentially nefarious, it just means that in the limited time that I had to look into it, I didn’t find anything alarming. I have been able to see it in Activity Monitor while it is actually running, in which case it will appear as “Google Software Update.” It seems to handle things such as uploading crash reports if any are available, as well as checking for updates of Google’s apps, such as Chrome. These are not services that will keep running indefinitely, they are only started periodically to check for updates or when a Google app wants to talk to them, which makes the claim that they slow down WindowServer even more interesting.Īs to what this updater agent does, I’ve done some basic reverse engineering by statically analyzing the binaries involved using Hopper. The other one, “Keystone XPC Service” is started only when a Google app wants to check for updates itself, on demand. The “Keystone User Agent” service has a StartInterval set to a value of 3623 seconds, so it will run roughly once per hour to check for updates. In the case of the Google Chrome updater, it registers two services, which are backed by the same binary, located at ~/Library/Google/GoogleSoftwareUpdate/GoogleSoftwareUpdate.bundle/Contents/Resources/GoogleSoftwareUpdateAgent.app/Contents/MacOS/GoogleSoftwareUpdateAgent. Launchd is the daemon responsible for spawning processes on macOS, and a launchd property list is basically a configuration file that tells launchd how it is supposed to treat a given service. Google’s Keystone service, just like any other service-type apps and processes that run on a Mac, registers itself with the system by employing a launchd property list. ![]() When does the updater process run and what does it do? I don’t see why Google’s Keystone updater would have to do this, and some quick static analysis of its binaries hasn’t revealed any such tactic. The only practical way I found to do this was to monitor the system for running processes and if Activity Monitor is found, terminate my process so that the user won’t see it in Activity Monitor. I do not have a definite answer for this question. Those questions were: Is it possible for a process to hide itself from Activity Monitor while it is running? When does the updater process run and what does it do? Is the Google Chrome updater actually the cause of this WindowServer CPU usage that people are seeing? Is it possible for a process to hide itself from Activity Monitor while it is running? What piqued my interest was the technical side of this story, and some questions that I thought of while I was reading Loren’s report. I do have it installed because some things that I do online require it, but my browser of choice has always been Safari. Let me preface this by making it very clear that I’m not a fan of Google Chrome. Many users have reported that this does work and that after removing Google Chrome from their machines, everything got a lot faster. The website includes information on how to completely get rid of Chrome and its updater from your Mac to get your performance back, and went as far as calling it “malware” (that word has since been removed). This weekend, developer Loren Brichter released a website claiming that Google Chrome for Mac - or more specifically its auto-update mechanism - was causing the WindowServer process on macOS to constantly have high CPU usage, damaging the performance of macOS, even on high-end machines.
0 Comments
Leave a Reply. |