Archive Utility doesn't quit when finished in Mountain Lion

This is a known bug in the OS (10.8.2). It affects many applications (Spotlight, iTunes, Archive Utility, many 3rd party apps, eg BBEdit).

I haven't experienced the "doesnt quit when finished" issue, but then again I can't make it that far. As soon as you launch it, Archive Utility freezes (Application Not Responding) unti it times out and quits. But, I do know the issues are related; it's the same problem manifesting itsself different ways.

The issue is known as the "Apple Events bug". Apple is aware of it. The fix will absolutely require an OS update from Apple, so everyone just has to wait. No other choice.

I do have to say that my upgrade experience to Mountain Lion has been the buggiest and most dysfunctional experience since System 8 / 8.1 back in the mid-90's. I''m on day three since install and I can't make it two hours without having to stop and repair or investigate an issue.

Right now my list of apps I need to upgrade is approaching $1000 in upgrade license fees, and I have 7 apps that apparently will never work again as long as I live (or as long as I resist the urge to downgrade to Snow Leopard, anyway). My typical costs to upgrade are in the order of $200 when a new OS is installed.

But it's frustrating when that is accompanied by System-wide bugs like this one that affects Apple bundled software. Not good.

A Summary of the bug, courtesy Brian Webster:

" ...

The basic outline of the problem is that sometimes a particular application will get into a state where any events sent to it using

AESendMessage

AESend

AESendMessage

errAETimeout

..."

It was apparently introduced in the 10.8.2 update. So if you are running 10.8.1, consider waiting for 10.8.3.

A temporary fix is to logout and login again. That will work until the bug manifests itself once, then it will affect everything until you logout again.

Not every app uses the routine described above (there is an alternate that could be used) but many do, including many apps supplied as part of the OS install. Any one of them could potentially be affected at some time or another.

I found the fix...

restart holding option and access 10.8 drive then repair permissions in disk utility. This DID NOT work using the systems regular disk utility.

Everything is working great now!

FFHamilton wrote:

I found the fix...

restart holding option and access 10.8 drive then repair permissions in disk utility. This DID NOT work using the systems regular disk utility.

If that is what you did, you booted up normally, no difference. If however you mean boot using cmd-r (recovery) you may be correct (for your situation). As it stands your post makes no sense.

RE: Post by FFHamilton

Rebooting will work but is un-necessary. All you have to do is logout, then log in again.

This is a system-wide Operating System bug introduced in the 10.8.2 update or install (that presumably will be fixed with the next OS release).

You should be able to use (in your case) Disk Utility after a reboot or login. The nature of the bug is it will not typically show the first time you use an affected app.

At some point you will notice strange behaviour. From that point on all affected apps will also be affected; ie it's like s switch was set. Once the error has been experienced, a logout / login will again reset the system to error-free (for a while).

EDIT: I was surprised on first read that Disk Utiliity was affected. On re-read I now understand you meant to write that [some app] was affected, and then your fix was to launch Disk Utility and repair permissions on a volume. This is not a permissions issue. When you shut down you fixed the problem; the repair permissions had no effect on it.

Confirming the same, experienced the same behaviour on a few systems running 10.8.2:

gordguide wrote:

The nature of the bug is it will not typically show the first time you use an affected app.

At some point you will notice strange behaviour. Once the error has been experienced, a logout / login will again reset the system to error-free (for a while).

And thanks for the details in a previous post, about this erroneous behaviour being related to a Mac OS X 10.8.2 "Apple Events bug".

(...so much for previous messages suggesting that one should "spend a bit more time checking out the third-party apps on your system before jumping to the conclusion that it's the OS" or that one "did post a reply awfully quickly" ...)

Yes, well, Mitja, they are only trying to help in the way they know how, which is to defend Apple from arrows slung into the fortress. There are WindowsOS counterparts; I say let them have their fun.

The vast majority of current MacOS users are relatively new Apple computer users so they feel a need to defend thier choices. Most consumers feel a need to defend whatever it is they buy; computers are no different.

I've been using MacOS systems for two decades; my "defense" of Apple is pretty weak ... it's the best tool for the work I do.

I am also able to fix most issues myself, which is why the 8 or 10 issues I've asked for help with here are all unsolved. As are the two support tickets I've opened with Apple over thsoe years (elevated to 1-on-1).

My "rule" is to spend up to a maximum of 40 hours of my time on any given issue and if it can't be fixed by then, I move on. This particular issue took me about half an hour to figure out. The workaround (logout / login) is OK for now; the "fix" is to just wait. Which is what I suggest everyone do.

The "OS X Mountain Lion Update v10.8.3 (Combo)" http://support.apple.com/kb/DL1640 seems to solve the issue, without any other change in the system. It was apparently a bug introduced in a previous 10.8.x update, and it seems that it has been fixed in the 10.8.3 update.

Updating a few 10.8.2 systems using the "OS X Mountain Lion Update v10.8.3 (Combo)" available at http://support.apple.com/kb/DL1640 appears to solve this issue.