I’ve run into a problem the last couple of weeks that is bewildering. I’ve been using GUI scripting and System Events for a long time without problems. But now, whenever I launch System Events for even the most trivial task (it doesn’t matter what the task is), it runs rampant taking up as much as 90% of the cpu activity as demonstrated by Activity Monitor. Attempts to quit it fail unless I perform a force quit via Activity Monitor. Even compiling a script that involves targeting System Events (without actually running the script) causes the same out-of-control behavior (perhaps due to activation of System Events to resolve terminology???) Coupled with this phenomenon, I now find that any script involving GUI scripting and System Events executes very slowly, perhaps five-fold more slowly than formerly, including scripts that have been executing smoothly for over a year of regular use. In addition, I’ve been getting a lot of “connection” and “process not found” errors, which I’ve attribued to the fact that System Events is so busy doing whatever it’s doing that it doesn’t perform the tasks I’m asking it to properly. But what is it doing? Why is it doing it? There is no specific code that brings on this behavior. Any “tell System Events” command does it.
Just as a couple of examples, the following simple commands are sufficient to initiate the hyperactive System Events behavior (it really doesn’t matter what the code is):
tell application "System Events" to get its name
-OR-
tell application "System Events" to tell process "Finder" to return UI elements
Please, can anyone help me to understand what is happening here? It’s almost as if something very fundamental has gone awry, but I am at a loss to know what. Thanking you very much in advance for any help with this.
Thank you for your suggestions. I force quit System Events and SystemUIServer, and trashed their plist’s, but the problem recurred just as before when I ran the following simple script:
tell application "System Events" to get name
Then, as you suggested, I created a new “test” user, logged in under that user, ran various “System Events” commands, and voila! No more problem. The cpu activity dwindles to zero immediately after completion of the “System Events” tasks just as it should.
So logging in as a different user solves the problem. What does that suggest as to the cause of the problem? What should I do to fix the underlying problem? Thank you so much for your assistance.
It says that the problem is in your original user domain - but then
it could be with any user process, also with System Events or others…
It could also be a user script or app that remains calling System Events.
(do you have any exotic SW or HW around?)
I see 3 ways to proceed:
Make the affected user as clean as possible, i.e. quit or force quit
processes one by one from Activity Monitor. Recheck whether the problem persists.
As soon as it is gone, you should know which process is affected.
That however does not say which file is affected, alas…
Start out with a completely new preferences folder.
After the system has re-initiated some critical prefs, start putting back your old prefs
(one-by-one) or (bunch-by-bunch), log out and in, and see whether the problem reappears.
Put the affected user prefs
(one-by-one) or (bunch-by-bunch) into the stable test folder, log out and in, retrying whether the problem reappears.
I can’t guarantee that this works, but it may be faster that reinstalling a new system.
(.or not)
Eelco, thank you for those detailed instructions. I will try each one and see if that homes in on the problem. If it turns out to be a problem app or preference that is causing System Events to run rampant, it might be evolve into an interesting learning experience. I’ll let you know. - bmose
Back in Pre-X days, there was a very useful program for doing this: ConflictCatcher. The key to its method was a binary search for the offending extension. I would suggest removing all non-Apple preferences and restarting, then dividing those removed in half and loading half back, restarting. If the fault occurs again, remove that half, divide it in half, etc. That way you only have to do N restarts where N is such that 2^N > Number of Prefs to test.
If, on the other hand, the fault occurs with only the Apple Preferences in place, then I would do an archive and install of OS X and then do the updates. There is a combo for 10.4.7, and individuals to get to 9.
That’s an interesting variation from mine.
Both have drawbacks: if a conflict exists between two extensions, it will be difficult to sort out…
This is less probable, but still very possible in OSX.
It’s been a while since the last post, but just thought I’d leave the results of my efforts now that the “runaway System Events” problem is solved in case it helps others in the future:
Deleting running applications in part or in whole did not correct the problem.
Deleting my entire ~/Library/Preferences file did solve the problem. I deleted the Preferences file (after saving a copy) and for the past month have been creating new plist files for my applications one-by-one. I have now been back up and running for a month without any hint of that nasty problem re-emerging. My guess is that the culprit was a plist file of one of my AppleScript applets that targeted System Events. There were quite a few, so I don’t know which one it was.
Eelco and Adam, many thanks for your invaluable help in getting me back up and running.
Jon Nathan has written a neat app for testing Preference files called “Preferential Treatment” that is quite useful for finding plist files that are ill-formed.