Error -10810 Opening Applications or Relaunching Finder

Error -10810 is a Launch Services result code indicating an unknown error. One cause of this error is that the Mac® OS X process table is full. When the process table is full, new (not currently running) applications cannot be opened until another running application ends. Programming errors in third-party applications can fill-up the process table, leading to the -10810 error when opening an application.

This FAQ discusses: the background of this problem; its history, reported workarounds, and general troubleshooting advice; and provides a procedure for identifying the process or processes that are filling the process table. It is based upon extensive research of this problem on the Web, especially a 2009 Apple® Mailing Lists post by contributor Terry Lambert. This FAQ expounds upon Terry's post in an attempt to make the cause and resolution of this problem more accessible to the general Mac OS X user.

Background

All running programs on your Mac are processes. This includes both applications that you open and faceless background processes, i.e. processes without a graphical user interface (GUI), such as mds (the Spotlight metadata server) or cupsd (the CUPS printing daemon). Activity Monitor shows a list of all running processes. Finder® is an application, hence it is a process.

Processes can launch other processes, known as child processes. For example, the launchd (launch daemon) process opens many background processes when you start up or log in to your Mac; launchd is the parent process and each process it opens is a child process of launchd.

Mac OS X tracks running processes in a process table. Mac OS X has a default limit of 266 user processes per account. You can see this limit by issuing the Terminal command ulimit -a and noting the max user processes value. Once this limit is reached, the process table is full: new processes cannot be started until a currently running process terminates, hence new applications cannot be opened. If you attempt to open a new application when the process table is full, an alert dialog will appear showing error code -10810, e.g.

The application appname.app can't be opened.
-10810

where appname is the name of the application you attempted to open.

If Finder is hung and you attempt to relaunch it when the process table is full, an alert dialog appears with the message:

The application Finder.app can't be opened.
-10810

The limit of 266 user processes per account is set high enough that it would be virtually impossible for a user to open enough applications to fill the process table (the default limit is different under Mac OS X Server). Programming errors, especially in third-party applications, can lead to three general causes of a full process table: zombie processes, fork bombs, and runaway processes.

If an application (process) that creates (spawns) child processes either crashes or fails to properly clean up (reap) its child processes, the child processes become zombie processes. Zombie processes are essentially dead process that consume process table entries. Since they are not running, zombie processes do not appear in Activity Monitor.

If an application contains a fork bomb programming error, the application repeatedly opens new instances of itself; each new instance takes an entry in the process table until the process table is full. A variation of this is where an application that spawns child processes encounters an infinite loop bug in its child-creation process, thereby filling the process table with instances of the same child process. Such an application is a runaway process. In Activity Monitor, one or both of the following conditions may be seen:

  • The fork bomb or runaway process name may appear in red and display (Not Responding).
  • The process list may be filled with many copies of the same process name with different PID (process ID) numbers. The repeating name may be that of the errant process itself or child processes of such.

Once the process table is full, the system log file system.log will show blocks of proc: table is full messages.

History, workarounds, and general troubleshooting

The -10810 error has a long history in Mac OS X, especially in Mac OS X 10.6 Snow Leopard® where one Discussions topic — concerning -10810 and Finder — has collected hundreds of posts over the years. Some speculate that a bug in Mac OS X is at the heart of the problem. Nevertheless, Apple has yet to publish a fix or a Knowledge Base article for this problem, implying that Apple's own research has determined that this is not a Mac OS X bug.

A number of workarounds have been suggested for this problem, but they generally do not address the root cause: why the process table is full.

One oft-cited workaround recommends specific Terminal commands to (temporarily) restart Finder. Some claim this to be a "fix" when it is merely restarting Finder and not addressing the underlying cause.

Some advocate resetting Launch Services as a solution, but -10810 issues are generally not a problem with the Launch Services database: the problem is usually due to a filled processs table.

Accessing external hard drives, RAID arrays, shared volumes, or network-attached storage (NAS) has often been attributed to the -10810 problem, again leading to speculation about a Mac OS X bug. Nevertheless, many of these reports do not consider the possibility of problems on the disk they are mounting — directory corruption, bad sectors, a defective drive — or that an errant kernel extension for their third-party storage device may be the problem. These disk-related problems may cause conditions where the process table is filled, such as the endless spawning of smbd processes. If -10810 errors arise after connecting external drives, check the drives with Disk Utility. Bad sectors can be identified with the Surface Scan feature of Micromat® Tech Tool® Pro.

Some users have taken dangerous steps when this problem appears after connecting an external drive, such as physically disconnecting the external drive without first ejecting (unmounting) it. Disconnecting an external drive before ejecting it can damage the drive's partition map, rendering its data irretrievable except possibly via data recovery techniques. It is better to shut down the Mac, then power-off and disconnect an external drive if problems with an external drive are suspected. In certain cases, replacing bad hard drives or zeroing a drive to map bad sectors out of service (aka sparing) solved the -10810 problem.

In other cases, some have reported solving the problem by erasing the startup disk (Macintosh HD), reinstalling Mac OS X, and then individually reinstalling their applications. This solution may have worked because the fresh installation of both Mac OS X and third-party applications omitted some obsolete or defective third-party kernel extension or application, respectively, that was filling the process table. Had they restored the system and applications from a backup, such as via Migration Assistant, Time Machine®, or a third-party backup and recovery solution, the problem would likely have recurred since they would restore the errant application or kernel extension.

More likely, programming errors in third-party applications are to blame, especially test versions of software in the Beta or Release Candidate stages of development. Unstable applications that litter the process table with zombie processes or that contain fork bombs are a sure path to a -10810 problem. A careful reading of some of the many reports on the Web of the -10810 error frequently cite third-party applications as the cause; uninstalling the offending application, updating to a later version, or installing the most recent stable version often solves the problem. If this problem has suddenly appeared out of nowhere, the latest third-party application you installed may be the cause. Do not use the application again and report the problem to the developer.

Third-party firewall or antivirus applications may contain a programming error whereby they deadlock themselves, again resulting in a situation that fills the process table. If you recently installed or updated such software, disabling or uninstalling it should resolve the problem. If this is the case, again report the problem to the developer.

Third-party kernel extensions for third-party hardware should also be suspect. If you have installed third-party hardware that also required the installation of associated kernel extensions, starting up in Safe Mode will prevent third-party kernel extensions form loading. Using your Mac in this way for several days may help rule out applications as the cause of -10810 issues. If -10810 errors return after restarting your Mac normally and using third-party hardware, this implies either the third-party hardware or the associated third-party kernel extensions are the cause: troubleshoot the hardware per its manual or contact the manufacturer.

If you are unsure of the application that is causing the problem — or if more than one application may be at fault — the Procedure below should identify the culprit.

Procedure

Use this procedure is to identify and terminate the process or processes filling the process table. It expounds upon the process specified in the previously-cited post by Terry Lambert.

Terminal, in the Macintosh HD > Applications > Utilities folder, is the tool for this task. You will need at least three Terminal windows (shells) open before the -10810 error occurs: once the -10810 error occurs, it will be virtually impossible to open Terminal. If you are prone to making typographical errors in Terminal commands, it helps to open four or more Terminal windows.

Identifying the errant processes will use the ps (process status) command. Terminating the errant processes will use the kill command, the killall command, or both.

It may be necessary to preface these commands with the exec command. The exec command executes the command that follows it in place of the current shell, i.e. without creating a new process. This may be necessary since the process table is full. The downside of this is that exec effectively performs a log out of that shell once the command it prefaces has executed, preventing further commands from being issued in that Terminal window; this is noted by [Process completed] appearing after the output from the command. This is another reason why it is important to open multiple Terminal windows before the -10810 error occurs.

1.
 If your Mac is stuck in a -10810 error condition, shut down. If you cannot access the Apple menu to choose Shut Down, attempt to shut down using the associated keyboard shortcuts.
2.
 Start up or restart your Mac in Safe Mode.
3.
 Log in to the affected account. Presumably, this is your account.
4.
 Prepare Terminal for troubleshooting. You will need at least three open Terminal windows when the -10810 problem occurs.
4.1. Open Terminal, located in the Macintosh HD > Applications > Utilities folder. Terminal opens a single window (shell).
4.2. Open two additional Terminal windows: in Terminal, press Command-N twice. Second and third Terminal windows open.
4.3. Position and size the three Terminal windows so that they do not overlap.
4.4. If you do not have a preferred custom Terminal setup, create a Terminal Window Group to assure that opening Terminal always opens three windows:
4.4.1. In Terminal, choose Window > Save Windows as Group…
4.4.2. In the resulting Save Window Group dialog:
4.4.2.1. Type a name for the Window Group or accept the default.
4.4.2.2. Select Use window group when Terminal starts.
4.4.2.3. Click Save.
4.5. Set Terminal preferences to assure that Terminal windows do not close if a Terminal command ends the Terminal session:
4.5.1. Open Terminal preferences: in Terminal, choose Terminal > Preferences…
4.5.2. Click Settings.
4.5.3. Click the Shell tab.
4.5.4. In the When the shell exits: pop-up menu, choose Don't close the window.
4.5.5. Close (Command-W) Terminal Preferences.
4.6. Quit (Command-Q) Terminal.
5.
 Determine the Login Items set for the account. Third-party applications that are opened as Login Items may be responsible for filling the process table: knowing the applications that are opened when one logs in to the account may help in isolating the problem.
5.1. Open System Preferences.
5.2. If the lock in the lower-left corner of the System Preferences window is locked, with the message Click the lock to make changes:
5.2.1. Click the lock.
5.2.2. Type the Admin account name and password to authenticate.
5.2.3. Click OK. The lock now appears unlocked.
5.3. Click your account.
5.4. Click the Login Items tab.
5.5. Make a list or take a screen shot of the list of Login Items. If a scroll bar appears in the list, scroll down for additional items.
5.6. (Optional) Set Terminal as a Login Item for the account, i.e. to open automatically when you log in.
5.7. (Optional) Set Activity Monitor as a Login Item for the account.
5.8. Quit (Command-Q) System Preferences.
6.
 Restart your Mac.
7.
 Log in to the affected account.
8.
 If Terminal was not set as a Login Item in step 5.6, open Terminal. Three terminal windows should be open; if not, in Terminal press Command-N twice to open two more Terminal windows. If you are prone to making typographic errors in Terminal, open more Terminal windows as a precaution: you may not get another chance to open usable Terminal windows once the -10810 error occurs.
9. If Activity Monitor was not set as a Login Item in step 5.7, open Activity Monitor, located in the Macintosh HD > Applications > Utilities folder.
10.
 Work as you normally would until a -10810 error occurs. Pay attention to applications that you open or other actions you take so that you can note exactly what you were doing before the -10810 error occurred. You may want to take notes when you open applications or mount external disks so that you can later retrace your steps.
11.
 Switch to Terminal.
12.

In one of the Terminal windows, type the following command, exactly as written, at the Terminal prompt:

exec ps gaxlww

This will end the Terminal session in that window (as noted by [Process completed] appearing at the end of the list), but yield an extensive, scrollable list of every process on your Mac (the window remains open because of step 4.5). Resize the window so that you can see the entire output. The command uses the ps (process status) command with options (gaxlww) to produce a specific output.

In the output, the following columns are used in troubleshooting:
UID User ID, the user ID number of the account in which the process is running. UID 0 indicates root or the system; UIDs 501, 502, etc. correspond to user accounts. Since you are the only human user logged in at present, there should only be one 5xx UID in the list, the one for your account. The errant process should be running in that 5xx account.
PID Process ID, the unique number assigned to that process.
PPID Parent Process ID, the PID of the parent process of a child process, i.e. the process that launched this process.
STAT State, the running status of the process. For troubleshooting purposes, the important value in this column is Z, indicating a zombie process.
COMMAND The path of the program associated with that process, including any arguments that were supplied when the process was opened.
13.
 Kill the parents of Zombie processes.
14.
 Kill fork bombs and runaway processes.
15.
 For any applications found creating zombie processes or behaving as fork bombs or runaway processes:
14.1. Do not open the application again.
14.2. If the application is a Login Item, remove it [-] from Login Items.
14.3. Report the problem to the application's developer.
14.4. Check for updates to the application or uninstall it.

Kill the parents of Zombie processes

The general procedure is:

1. Identify multiple instances of zombie processes with the same parent process (PPID).
2. Terminate the parent process identified in step 1 using the kill command.

The following example explains this approach.

In the output from the exec ps gaxlww command, zombie processes are identified by the following characteristics:

  • STAT column entry: Z
  • COMMAND column entry: The name of the parent process enclosed in parenthesis.

To find the parent process of a zombie process, examine the PPID (Parent Process ID) column entry for the zombie processes. The process whose PID is the same as the PPID of the zombie processes is the application creating the zombie processes.

A few zombie processes, especially if their parent process numbers differ, are acceptable: the zombie processes may be waiting for their parent processes to read their exit states before reaping them, at which time the zombie processes are removed from the process table. If the parent process dies — e.g., the application named by the parent process quits unexpectedly — the launchd process will normally become the parent process of the zombie processes and clean them up accordingly.

The problem arises when there are many zombie processes with a specific, running parent process. Zombie processes cannot be killed: one must kill the parent process of the zombie processes, then launchd will clean up the zombie processes.

The following hypothetical example of the exec ps gaxlww output shows many zombie processes. The ellipsis (…) indicate gaps in the output to save space in this presentation.

UID   PID  PPID CPU PRI NI      VSZ    RSS WCHAN  STAT   TT       TIME COMMAND
...
501 47822   202   0  46  0   446724  26844 -      S      ??    0:12.45 /Applications/ZombieMaker.app/Contents/MacOS/ZombieMaker -psn_0_12446686
...
501 47836 47822   0   0  0        0      0 -      Z      ??    0:00.00 (ZombieMaker)
501 47837 47822   0   0  0        0      0 -      Z      ??    0:00.00 (ZombieMaker)
501 47838 47822   0   0  0        0      0 -      Z      ??    0:00.00 (ZombieMaker)
501 47839 47822   0   0  0        0      0 -      Z      ??    0:00.00 (ZombieMaker)
501 47840 47822   0   0  0        0      0 -      Z      ??    0:00.00 (ZombieMaker)
501 47841 47822   0   0  0        0      0 -      Z      ??    0:00.00 (ZombieMaker)
...
501 47840 47822   0   0  0        0      0 -      Z      ??    0:00.00 (ZombieMaker)
501 47841 47822   0   0  0        0      0 -      Z      ??    0:00.00 (ZombieMaker)
...

The PPID (parent process ID) of each zombie process is PID (process ID) 47822, highlighted in red in the example above. Process 47822, the application ZombieMaker, is failing to reap its child processes, creating zombie processes that are filling the process table.

To terminate the parent process, issue one of the following commands in the second Terminal window:

  • kill PID
  • exec kill PID

where PID is the process number of the application creating zombie processes. In the example above, one of the following commands

  • kill 47822
  • exec kill 47822

will terminate the application ZombieMaker; launchd will clean up the zombie processes soon thereafter. Note that using exec in the kill command will end the session in that Terminal window, but if you have killed the correct process, you should be able to open additional Terminal windows.

Kill fork bombs and runaway processes

The general procedure is:

1. Identify the process ID (PID) for the application that either contains a fork bomb or is a runaway. In Activity Monitor, this process may be shown in red with the status (Not Responding).
2. Terminate the process identified in step 1 with either the kill or killall command.
3. If the parent process killed in step 2 spawned multiple child processes with a different process name, terminate the child processes with the killall command.

As in the example discussed in "Kill the parents of Zombie processes" above, it may be necessary to preface the kill or killall commands with exec for success. Using exec in these command will end the session in that Terminal window; if you have killed the correct process, you should be able to open additional Terminal windows.

The following examples illustrate this approach.

Example 1

In the following hypothetical example of output from the exec ps gaxlww command, the application Forkbomber contains a fork bomb that is opening multiple instances of itself:

UID   PID  PPID CPU PRI NI      VSZ    RSS WCHAN  STAT   TT       TIME COMMAND
...
502 62782   300   0  48  0  2721456   6228 -      S      ??    0:00.08 /Applications/Forkbomber.app/Contents/MacOS/forkbomber -psn_0_524416
502 62784 62782   0  33  0  2713156   5348 -      S      ??    0:00.07 /Applications/Forkbomber.app/Contents/MacOS/forkbomber
502 62785 62784   0  33  0  2713156   5364 -      S      ??    0:00.07 /Applications/Forkbomber.app/Contents/MacOS/forkbomber
502 62786 62785   0  33  0  2713156   5364 -      S      ??    0:00.07 /Applications/Forkbomber.app/Contents/MacOS/forkbomber
502 62787 62786   0  33  0  2713156   5376 -      S      ??    0:00.07 /Applications/Forkbomber.app/Contents/MacOS/forkbomber
502 62788 62787   0  33  0  2713156   5392 -      S      ??    0:00.07 /Applications/Forkbomber.app/Contents/MacOS/forkbomber
502 62789 62788   0  33  0  2713188   5404 -      S      ??    0:00.07 /Applications/Forkbomber.app/Contents/MacOS/forkbomber
502 62790 62789   0  33  0  2713156   5400 -      S      ??    0:00.07 /Applications/Forkbomber.app/Contents/MacOS/forkbomber
502 62791 62790   0  33  0  2713680   5392 -      S      ??    0:00.07 /Applications/Forkbomber.app/Contents/MacOS/forkbomber
...
502 62802 62801   0  33  0  2713712   5488 -      S      ??    0:00.07 /Applications/Forkbomber.app/Contents/MacOS/forkbomber
502 62803 62802   0  33  0  2713680   5488 -      S      ??    0:00.07 /Applications/Forkbomber.app/Contents/MacOS/forkbomber
502 62804 62803   0  33  0  2713680   5516 -      S      ??    0:00.07 /Applications/Forkbomber.app/Contents/MacOS/forkbomber
502 62805 62804   0  33  0  2713680   5472 -      S      ??    0:00.07 /Applications/Forkbomber.app/Contents/MacOS/forkbomber
502 62806 62805   0  33  0  2713680   5500 -      S      ??    0:00.07 /Applications/Forkbomber.app/Contents/MacOS/forkbomber
502 62807 62806   0  33  0  2713712   5528 -      S      ??    0:00.07 /Applications/Forkbomber.app/Contents/MacOS/forkbomber
502 62808 62807   0  33  0  2713680   5528 -      S      ??    0:00.07 /Applications/Forkbomber.app/Contents/MacOS/forkbomber
502 62809 62808   0  33  0  2713712   5504 -      S      ??    0:00.07 /Applications/Forkbomber.app/Contents/MacOS/forkbomber
502 62810 62809   0  33  0  2712916   4480 -      R      ??    0:21.39 /Applications/Forkbomber.app/Contents/MacOS/forkbomber
...

The COMMAND column of first line in the sample

/Applications/Forkbomber.app/Contents/MacOS/forkbomber -psn_0_524416

shows the path to the executable file (the forkbomber executable within the Contents folder of Forkbomber.app bundle) and the argument with which it was opened (-psn_0_524416). The remaining lines in the sample show process table entries for the copies of Forkbomber opened by the fork bomb. Note how the PPID of one entry points to the PID of the entry above it, e.g. PID 62810 was opened by (is a child process of) PID 62809, which was opened by PID 62807, etc., all the way back to PID 62782, the opening of Forkbomber.

To terminate all copies of a process with the same process name, we use one of the following killall commands:

  • killall process_name
  • exec killall process_name

where process_name is the name of the process (running executable file) to be terminated.

To kill all copies of Forkbomber — specifically, the executable forkbomber — we issue one of the following commands in the second Terminal window:

  • killall forkbomber
  • exec killall forkbomber

Note that:

  • The killall command is case-sensitive: the name of the executable process to be terminated must be typed in the same case shown in the output.
  • Using exec in the killall command will end the session in that Terminal window; if you have killed the correct process, you should be able to open additional Terminal windows if needed.

Example 2

In the following hypothetical example of output from the exec ps gaxlww command, the application BadApp is a runaway process:

UID   PID  PPID CPU PRI NI      VSZ    RSS WCHAN  STAT   TT       TIME COMMAND
...
502  1214   300   0  48  0  2736900  21884 -      S      ??    0:03.10 /Applications/BadApp.app/Contents/MacOS/BadApp -psn_0_323663
502 37567     1   0  25  0  2426128     96 -      R      ??    0:00.00 (bash)
502 37609     1   0  31  0  2426128    248 -      U      ??    0:00.00 (bash)
502 37637     1   0   0  0        0      0 -             ??    0:00.00 (bash)
502 37763     1   0  30  0  2435544    548 -      U      ??    0:00.00 (bash)
502 37808     1   0  31  0  2435544    548 -      R      ??    0:00.00 (bash)
502 37863     1   0  31  0  2426140    260 -      R      ??    0:00.00 (bash)
502 37866     1   0   0  0        0      0 -             ??    0:00.00 (bash)
502 37957     1   0  30  0  2435544    636 -      R      ??    0:00.00 (bash)
502 37966     1   0  28  0  2435544    636 -      R      ??    0:00.00 (bash)
502 37988     1   0   0  0        0      0 -             ??    0:00.00 (bash)
...
502 38188 38071   0   0  0        0      0 -             ??    0:00.00 (bash)
502 38189     1   0   0  0        0      0 -             ??    0:00.00 (bash)
502 38191 38156   0   0  0        0      0 -             ??    0:00.00 (bash)
502 38194 37865   0   0  0        0      0 -             ??    0:00.00 (bash)
502 38197 38184   0  31  0  2426128    204 -      U      ??    0:00.00 (bash)
502 38198 38190   0   0  0        0      0 -             ??    0:00.00 (bash)
...

The application that started the problem is BadApp. Activity Monitor might give a clue to this: the process BadApp may appear in red and display (Not Responding), indicating that BadApp hung. The multiple instances of (bash) in the COMMAND column are the result of BadApp opening a bash shell script that contains a fork bomb. It could have opened another child process in an infinite loop, in which case the name of that child process would appear repeatedly in the COMMAND column instead of (bash).

The process ID (PID) of BadApp is 1214; we terminate it by typing one of the following kill commands in the second Terminal window:

  • kill 1214
  • exec kill 1214

We next terminate all instances of the fork bomb shell script by typing one of the following killall commands in the third Terminal window:

  • killall bash
  • exec killall bash

Note that:

  • The killall command is case-sensitive: the name of the executable process to be terminated must be typed in the same case shown in the output.
  • Using exec in the kill or killall commands will end the session in that Terminal window; if you have killed the correct process, you should be able to open additional Terminal windows.

References

Knight, Adam. "When You Can't Start Programs Because of a -10810 Error." Mac Geekery. 11 May 2006. Last accessed on 20 July 2011.

Lambert, Terry. "Re: error -10810." Apple Mailing Lists, darwin-dev list. 5 September 2009. Last accessed 20 July 2011.

Singer, David. "Watch out for zombies!" Read This Blog. 17 April 2009. Last accessed 20 July 2011.

Solaar, Kel, et. al. "The application Finder.app can't be opened." Apple Support Communities. 30 August 2009. Last accessed 20 July 2011.
Did you find this FAQ helpful? You will find a wealth of additional advice for preventing or resolving Mac OS X problems in Dr. Smoke's book, Troubleshooting Mac® OS X.
Use of this site signifies your agreement to the terms of use.