The application Finder.app can't be opened.

Hi SamuelJohn,

I came to this thread by doing a search on the Finder crash and error message -10810. I also noted that many who reported the problem also reported having external drives connected. And many reported the same drive I have -- a WD MyBook. So I think it may be the same problem.

I also have a blu-ray writer that I've added to my second optical bay. And my optical bays are behaving strangely since this problem started. One of the potential "cures" on my list is to disconnect that drive.

I have an earlyish macPro quadcore 3 ghz with 10 GB of ram. Running SL 10.6.8 when the problem started. I was working on a large file in the 3D space of photoshop extended when I started crashing and losing work. I thought it might be a ram issue then. On my first trip in to the genius bar they told me my boot drive had gone bad. I had them replace it with a larger drive. But I was getting more app crashes, disk utility wouldn't recognize *any* volumes sometimes, finder would crash and couldn't be relaunched, -10810 message, and even times when I would try to shut down the computer would hang and had to be turned off by the power switch.

the odd behavior in the optical bays is that when I'd try to open a drawer I'd get an alert that I had inserted a blank disk and what do I want to do (eject or open some program or cancel). But there either wasn't any disk in the bay or it wasn't a blank disk, and no choice would get the drawer to open. The only way to get it to open would be to restart and hold down the eject button during reboot.

But all the weird behaviors were sporadic. On a particular boot you could never tell how far you'd get.

the time before last that I brought it in to the genius bar it seemed to be on good behavior for the tech. But before we were done one of the volumes disappeard from the finder. We pulled it out and reseated it, and thought maybe that was the solution to everything. He thought if that didn't fix everything the next step would be to check the jumper settings on the bluray drive I'd installed, and beyond that we should look at the cable that runs between all the internal hard drives.

I got home and the problems started back up. I did pull out the bluray writer to check the jumper settings but it doesnt seem to have any.

I saw reports on this list that installing Lion had fixed the problem for some. So I downloaded Lion onto my WD MyBook. That did not solve the problem. It was only later I deduced that the MyBook might be a source of the problem.

The last time I brought it in they kept it for more diagnostics. They called this evening to say they were finding a problem with that cable between the internal hard drives and were going to order the replacement. So I'm waiting for that to come in before I can report back. If the cable doesn't fix it I'll apply some of the fixes that have been reported like on cnet.

the last time I tested my ram it seemed ok, and it wasn't that long ago. I assume the techs at apple tested that the first time I left it there but I don't know for certain.

I am not so tech savvy to claim I could read the console app and know where things are going wrong, but I'm happy to try that if it will provide any helpful info.

Message was edited by: chairboy

Chairboy, thanks for the info. Please report further.

Well then, I guess I am running out of options - you have already tried most things I'd suggest. But this all seems to be really more a hardware issue.

Let's see and hope what that cable replacement brings. *fingerscrossed*

If you have access to another Mac, you could try to see if the external drive works on that one. The console app could perhaps at least give some hints. It notes down all different kinds of status messages. Usually some USB, io or finder related messages might help us. But I guess the genius guys already did this when the error occured.

cheers,

Samuel

If Apple does not listn to their customers here they will be heard someway ...!

Android docet....

How to fix the "The application Finder can't be opened (-10810)" error

Snow Leopard has brought an annoying bug. Sometimes, when dealing with external hard drives or USB sticks, Finder crashes and does not automatically reopen. Trying to click on the Finder icon in the Dock does not help at all! It just causes a laconic message box that says: "The application Finder can't be opened (-10810)". Unless you want to logout and login back (or restart), the solution is simple but a little bit for the techie:

• Open up the Terminal application (use Spotlight if you cannot find it)
• Type: /System/Library/CoreServices/Finder.app/Contents/MacOS/Finder &
• Press enter and... You're done! You can close the Terminal

Waiting for a fix in 10.7.3... I hope this helps. Bye!

I am convinced that this problem is related network related because the finder is crashing when multiple connections are taking place... like ftp downloads, Outlook, and Safari. However, using Quickkeys to send a command to the Terminal doesn't always or usually work. Terminal freezes along with Finder, Dock, etc.

I personally had this problem as well, where once in a while if I tried to shut down the computer the menubar would disappear, but the dock would stay intact (though without the indicator lights) and if I clicked finder this error would pop up. I would have to open an app to show the menu bar and hopefully it would shut down (I would keep selecting shut down). I'm not sure whether the problem I experienced is similar to yours (probably is not), but I went to console one day and I realized that every time this happened pando media booster had crashed. I'm not even sure when or how this got installed but I immediately went to application support and removed the folder for it. After that i never experienced this probelm again.

One for the Mac OS X hackers amongst us - many apologies if this post is overly techy for some of the contributors here.

I'm running 10.6.8 up to date on a variety of machines, the vast majority being genuine Apple hardware. Main workstation is a proper Mac Pro 3,1 but it has a LOT of peripherals and a very heavily loaded USB bus (30" ACD, 27" LED CD, two powered hubs and lots of accessories including a random FPGA running specialised software).

The main workstation is relatively stable and reliable. However, this Finder error is still present and occurs sporadically. Sadly I have no answer to the problem outside of the 'Microsoft Way' (i.e. reboot) which is, to me, entirely unsatisfactory for a Unix machine. But I do *think* I've narrowed it down to one specific issue.

When an external volume is connected, regardless of filesystem or means of connection (USB flashdrives, USB enclosures for mechanical drives, network connections (SMB, NFS, AFP, even extremes like iSCSI endpoints), Firewire enclosures (400/800, mechanical, SSD, custom RAID), eSATA interfaces), the usual Unix mount process kicks off, but this is controlled by an OS X-specific daemon called diskarbitrationd. Once the new volume is mounted, other processes hook into the new volume - often the filesystem is checked for errors (common to most Unix flavours), and as standard, OS X-specific processes become part of the chain, such as fseventsd (allows filesystem events to be collected and made available to other apps, for example preventing Finder from having to poll an open folder if you've just put a new file there from an external app - and obviating any need for 'refresh' of open folder windows) and mds (Spotlight search) opens the filesystem for indexing.

I find that the Finder lockup problem occurs only when there's a problem dismounting the external volume (or the external volume disappears, OS X tries to recover by forcing a disconnect (umount -f) but the endpoint is no longer there) and umount hangs. Looking at the process list, there's often an /sbin/umount -f /Volumes/Whatever command still running (long after the volume concerned disappeared from your Finder and /Volumes filesystem), and hence both fseventsd and diskarbitrationd (and mds, if running) are stuck in a 'U' state - i.e. Uninterruptible Wait. This is a hang, as far as the user is concerned, and no other volume-dependent messages can be passed to diskarbitrationd, hence the Finder won't start (even if you start it from the Terminal).

I've tried doing a kill -9 on the stuck umount process as root but, since it's waiting on a hardware ACK that won't ever arrive, it doesn't die. Hence it doesn't send messages down the chain to fseventsd and diskarbitrationd, and we have the Finder problems.

There should be some way of forcing diskarbitrationd to 'abandon' a particular volume - releasing the locked wait for a reply from the dead hardware (in my case, dead USB flashdrives are the VAST majority of causes of this problem). I understand that this would be very dangerous - passing this command to a connected, alive volume would probably cause corruption - but plenty of other Unix commands can trash the system.

Does anyone here with better OS X hacker skills than me know whether diskarbitrationd can be passed such a message, or whether fseventsd can be used to pass the required 'this volume's gone, mate, give up on it' message to the main daemon? The trouble is both are in 'uninterruptible wait' state so probably won't listen to anything other than SIGTERM...

I'm a bit wary of simply killing core daemons like diskarbitrationd since I could end up corrupting every connected volume (and I've got a lot going on)...

There may be other very specific cases that are different, but I believe the majority of these Finder problems are caused by this chain of events resulting in an Uninterruptible Wait for diskarbitrationd. Simply releasing the lock would let everything flow again without a reboot... well at least I'd hope so, for a properly designed Unix system.

It's obviously a fundamental problem since we've got 46 pages of commentary and it's not just happening to newbies or people with obviously bad hardware. I'm not accepting the 'solution' of 'upgrade to Lion' - besides, someone here has said that it still happens with Lion. I may try the 'nuclear option' of killing either fseventsd or diskarbitrationd, but I wouldn't recommend it. Really I need a response from an OS X core Unix system engineer who knows a LOT more about the OS X underbelly than I do. I'm no guru, but I'd happily accept a solution that involves tricky CLI stuff for the time being...

Thanks for this most verbose analysis. If it holds, the problem can be reduced to distinguishing between a temporary unavailability of an external device and a premanent one. That could be handled by a time out or user interaction, and in fact Finder always seems to ask if a suddenly missing network share should be disconnected. I don't think this is the whole story, which is likely a more complex issue.

I'm also still on 10.6.8 and in my case, it turned out I had some memory issues with my main server. Since I ran Memetest, found the bad RAM and replaced it, I haven't had a single Finder issue as reported in this thread in weeks. I don't leave USB keys plugged into my system unless it's to transfer data in and out, but perhaps your analysis holds truer for USB and other external connected storage devices.

How an OS deals with a faulty storage device seems to be an endemic problem with most operating systems. It seems to be true enough with OS X and Windows, but I don't know enough to know if Unix is any better. I believe the problem is that storage devices still don't interact with OSes with enough information to allow the OSes to make a quick decision with regards to unavailability or failure. SMART doesn't seem to work unless it's an absolute failure scenario and in fact in most of my hard drive failures, SMART was never actually tripped to show failure before the data became unavailalbe. I think SMART is a great idea but it's not 100% foolproof or revealing. Even if it worked. a lot of external USB chipsets (and certainly most if not all USB keys) don't communicate SMART data at all, and this would also make it likely that these problems occur more typically with them as no other indication of failure exists other than the inability to write to, or mount, the device.

So this appears to be an industry wide problem. Perhaps in the case of USB keys, some intelligence in the form of better status reporting and ECC correction could clean things up. In the case of drives, better and more intelligent acquisition and handling of SMART data by the drive and OS manufacturers would help. And in the case of shares, perhaps time outs should be less forgiving and some health reporting from the server and better analysis from the OS could work.

In all cases I could see a mixed data flow of clean and corrupted data coming from a device fooling the OS into thinking the device is "sort of" working, to which the OS responds with requests for resends to which a portion are successful. The only way to mitigate this is to have some kind of expected data rate the OS can interpret as a a baseline below which the user is prompted to disconnect or terminate transfer. Sometimes you do want to do this for a failing device to attempt to retrieve what you can from it, but many times you just want to disconnect. But to my knowledge no method of establishing this baseline exists, so I can see this SNAFU as being a common occurance and certainly an explanation for this frustrating behavior. One solution is to monitor the number of bad data packets being transferred in both directions and just use that as the baseline for establishing that sub-standard transfer is occuring and for then asking for user interaction.

In the end, just this angle is a lot of work for everyone involved and the question is always how much money do you throw at a problem that only affects a small proportion of users and is a good source of profit to the repair and maintenance businesses, not to mention the PO... 😉

I did find a very good answer to this on an old developer BBS, but it's been taken down.

The solution that worked for me was to use Activity Monitor to check all the processes that were running on the computer. The Finder error can be the result of too many processes running simultaneously.

In my case, I had misconfigured a piece of software that was spawning multiple processes. Fixing that underlying problem fixed the Finder errors.

It has nothing to do with Lion vs. Snow Leopard, at least in my experience.

Steve

This issue and possible workarounds and fixes were posted to MacFixIt in 2009. Do none of these help?

here is the solution:

http://utvv.blogspot.hu/2010/01/how-to-fix-application-finder-cant-be.html

just type this in Terminal and hit ENTER:

/System/Library/CoreServices/Finder.app/Contents/MacOS/Finder &

et voilá!

That is a workaround to get the Finder to reopen. It is not a solution, by my definition, as it does not permanently eliminate the problem. The Finder may still crash and produce the error upon attempt to reopen. This is not a universal issue on Macs, so I would expect a solution to fix it.

You can avoid doing a reboot, but not without upsetting whatever you are doing on those drives you might have connected, which in some of the complaints, were the reason to avoid the reboot in the first place. You have to go to relaunch Finder. It fails with the message, but if you pull your connected drives from the USB ports and give it a moment, you can plug them back in and launch Finder as normal from the dock.

Bravo!

Kind thanks for your help. Such a simple fix.

I can't believe people have been having this issue since 2009, at least. In any case, yes, I couldn't see any icons on my desktop and had no access to my Hard Drive. Your terminal trick worked so nicely and all the icons just popped right up! So, again, a very nice fix in Terminal!

It was like a magic trick, followed by a good glass of scotch! 🙂

That doesn't work for me. I have no choice but to force quit my macbook pro every time this error pops up.