With syspolicy running at 98% CPU capacity I checked syspolicyd on Console and it returned the following error: "failed to call driver: 0x3".
What do I do next?
How can I determine what driver is affected? Or the process calling the driver?
BTW, I tried updating software - nothing to update.
MacBook Pro: Late 2013
macOS: Big Sur, 11.7.10
Earlier Mac models
Hi John. thanks for your response.
I saw that a couple of programs were having difficulty starting, e.g., Spotify. I removed these. In addition, the MacBook 2013 (my teenager's) can only be updated to Big Sur and there was update was set to "automatic". The update process was runniung whihc couldn't be resolved; I switched this back to manual. After these issues were taken care of, the above mentioned syspolicyd mesage disappeared and the performance of the device improved considerably.
Nevertheless, following a restart the syspolicyd process consumes a considerable amount of CPU for a few mintues before reverting to about 8 - 10% CPU. That's obviously still an issue but probably a different issue, which I'll have to take a closer look at.
BR Diarmuid
Please determine if the same problems occur in "Safe Mode": Start up your Mac in safe mode - Apple Support.
Couple observations on an iMac I happen to be using:
Nevertheless, following a restart the syspolicyd process consumes a considerable amount of CPU for a few mintues before reverting to about 8 - 10% CPU.
Normally syspolicy is doing nothing on that Mac: 0% CPU. However, upon restarting that Mac it exhibited the same behavior, with syspolicy occupying roughly 50% CPU for perhaps twenty seconds. Since it is rarely necessary to restart Macs (this one had been up for about three months) I suggest that particular anomaly is not a factor.
If you identify a particular app or process occupying an inordinate amount of CPU time in the Activity Monitor app, it's not a bad idea to use Console in an effort to track down the cause. However, even Activity Monitor adds to the CPU load, but more importantly Console is a lot more burdensome. It was educational to identify syspolicyd as a culprit but the information it provides ("failed to call driver") does not tell us which driver was causing the difficulty. 0x3 is just a number (three). The only way to do find out which driver it may be is to methodically eliminate each specific system modification as a cause. Spotify was a good guess since you already knew it was problematic. Most likely it was attempting to sign in to a Spotify account and was having difficulty, but who knows why. If you want to track down the cause you'll have to do more investigation along those lines.
To identify potentially contributing factors EtreCheck is a good tool that won't burden a Mac unless it's actively running: https://etrecheck.com/en/index.html
Obviously don't leave Console up and running all the time. It will have a detrimental effect on a Mac's performance. Same goes for Activity Monitor, but its effect is much less.
2 Cents here
Rooting around in the Console Logs to Trouble Shoot was fine back in the days of OSX 10.6 Snow Leopard
With each newer version of OS X / macOS the usefulness of Console Logs had been deprecated.
Deprecated to the point where most of was appears in the logs are Software Engineers taking to one another is a language only they would understand
Unless there are serious issues affecting the computer
I would suggest not driving myself mad / crazy looking in the logs
Console returns error report on syspolicyd: "failed to call driver: 0x3".
