The shell command...
...will monitor all the function calls being made by the Finder and create a text file showing the call stacks of each of the Finder's threads. Even knowledgeable non-programmers (super users, if you will) can often glean valuable insights from this. It's also a great thing to attach to a bug report to Apple via http://bugreport.apple.com/ .
This is basically the same as the "Sample process" button in Activity Monitor.
Update: Ooh, even better than
spindump(8), which is like
sample but adds visibility into what the kernel is doing when the app's threads are blocked waiting for the kernel.
sudo spindump Finder
The text file it creates in
/tmp will require root privs to read, since it might contain privileged information.
More clues could be gleaned from...
lsof -p $PIDOfFinder
(where $PIDOfFinder is the process ID of the Finder, which you can find via
Looks like you can get that same information in Activity Monitor. Select Finder, hit the "Inspect" button, and select the "Open Files and Ports" tab.
Another interesting data point would be whether or not the problem happens for a new, clean user account on the same system. Just create a new user account, log out of your normal account (don't use Fast User Switching -- we don't want your "bad" instance of the Finder staying running in the background and confusing things), and log into the new clean account and see if the problem happens there too.
Are you running any InputManager hacks, including SIMBL-based stuff, or Unsanity Application Enhancer (APE) "haxies"?
Does the problem happen when booted into "Safe Mode" (that is, booted with the
<shift> key held down)?