Measure CPU and a hang

High CPU and an unresponsive window are symptoms, not causes. They are also independent. A process can spin at 100% CPU doing real work, and a process can also hang while waiting on a lock, file, network request, or another process while using almost no CPU at all.

The split tells you where to look. High CPU plus no progress suggests a busy loop or runaway work. A beachball with near-zero CPU means the app is blocked on something, and the interesting question is on what.

Activity Monitor gives you the first read: the % CPU column, and the process shown in red as “Not Responding” when its main thread stops servicing events.

Capture a short stack sample

Before you force quit, take evidence. sample records where a process’s threads spend time:

sample 1234 5 -file sample.txt

That samples PID 1234 for 5 seconds and writes a text report. Open it and find the call graph: an indented tree of function names with counts next to them.

Read repeated stacks to find where threads spend time. Follow the largest counts downward. If the main thread shows the same deep stack in nearly every sample — say, sitting inside a file-read call or waiting on a lock function — that stack names the wait. Function names from the app’s own code, visible in the tree, tell the developer exactly where it stuck.

For a hang that spans several processes, sudo spindump captures the whole system for a few seconds, which helps when app A is blocked waiting on app B.

Preserve context, then quit gently

Save the app version and reproduction with the sample. A stack trace without the version it came from is much less useful in a bug report.

Then, and only then, unstick the app. Use normal Quit before Force Quit when data may be unsaved. A hung app sometimes recovers when whatever it waited on completes, and normal Quit gives it a chance to save. Force Quit is the last step, not the first.