The shell command...
sample Finder
...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 sample(1) is 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 ps.)
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)?
I was digging around the other day and saw this message appear on the terminal: emulator: warning: opening audio input failed I've seen this message many times before and I had always assumed that it was because the emulator didn't support sound or something like that. But I decided to try an experiment that one particular day. Turns out the emulator has a "-noaudio" command line option, and when I ran it with that, it worked!! So now I just run emulator with the -noaudio option always, no freezes. No sound support either, but at least I can run the emulator now.
Now, that works if I manually call the emulator from the command line. What about when the Eclipse ADT plugin calls it? Well I was feeling rather lazy at that point and didn't want to dig around in the ADT plugin to see if it had a "add these command line flags whenever running the emulator" option, so I made a little "wrapper" shell script for the emulator command that always adds the -noaudio option. It's a bit of a kludge, but it works. Here's how: (note: $ represents the shell prompt, don't type it yourself)
$ cd <WHERE YOU INSTALLED THE ANDROID SDK>/tools
$ mv emulator emulator.real
$ cat > emulator << EOF
#!/bin/sh
exec <WHERE YOU INSTALLED THE ANDROID SDK>/tools/emulator.real -noaudio $*
EOF
Best Answer
Try this with an Ubuntu LiveCD (here) or GPartEd boot CD (here) or something similar where you can boot from CD and not your hard drive partition (assuming you have another computer where you can download and burn one of those). Even if they don't understand the HFS+ file system they will be able to read it in raw format.
This will be the safest way. For once, the operating system will not lock the drive and you won't run into the risk tha the swap file or temp files will overwrite the precious free blocks.