Suspect an issue affecting the WindowServer process (brief edition for power users)
The symptoms you describe are familiar but not commonplace and in my case, not frequent.
Diagnosis – at the time of the problem, if it recurs
Remotely,
sudo sysdiagnose
After you regain local control, you can analyse the end result.
Remotely,
top -o state
Processes that are stuck should be at or near the top.
Is WindowServer stuck for any length of time?
Workaround
If WindowServer is stuck, you might kill remotely –
sudo killall WindowServer
– but this will cause a local log out, so be prepared to lose unsaved changes.
This relatively short answer is tuned to the opening poster's confidence with remote ssh and bleeding edge stuff.
For a more detailed answer, accepted under a similar question where the cause of a problem may be different: Suspect an issue affecting the WindowServer process (long edition)
Suspect an issue affecting the WindowServer process (long edition)
The symptoms you describe are familiar but not commonplace and in my case, not frequent.
Prepare for diagnosis
In Terminal, run the following command. Be prepared to enter your admin password for the operating system:
sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.stackshot.plist
Take a written note of the following key chord, you'll need it later:
Control-Option-Command-Shift-.
Diagnosis by the system
When the problem occurs:
- use the key chord
- for at least ten seconds, touch nothing
- allow maybe five or ten minutes for all parts of the so-called
sysdiagnose routine to complete – simply wait as long as you can (with this approach there'll be no on-screen indication of progress)
- force a restart of the computer (Command-Control-Power).
After the computer starts:
- in Finder, go to
/private/var/tmp
- seek a file or folder with a name beginning sysdiagnose_
- if that file or folder exists, move it to a convenient place – your desktop, maybe.
Hint
Whilst I don't encourage carelessness, you can be a little careless with Control-Option-Command-Shift-. … if you struggle to avoid the fn key on your laptop, don't worry; including it by accident should not prevent the run of sysdiagnose.
Human analysis of diagnosis by the system
Hint: someone might like to ask a separate question about analysing the results of sysdiagnose – a more generalised answer could be useful.
If sysdiagnose_… from the /tmp area is a folder
Presence of a sysdiagnose_… folder (not a .tar.gz file) indicates that either:
- the routine was interrupted before completion; or
- some part of the routine could not complete.
If sysdiagnose_… from the /tmp area is a file
Presence of a sysdiagnose_….tar.gz file indicates that all parts of the sysdiagnose routine completed, and that the results were archived. If you wish, open the archive – its contents will appear as a folder.
Folder contents at a glance
In the first screenshot below – an example of a completed run of sysdiagnose - I have selected two of the items that may be of interest in a case such as this.
Note that it may be normal to find at least one empty file.
Amongst the .crash, .hang and .spin files – or in the top.txt file – might be a good sign of what was wrong shortly before, or during, the period when you lost control of the computer.
Related:
For an incomplete run of sysdiagnose it may be useful to focus some attention on files that are abnormally empty …
Technical
stackshot(1) OS X Manual Page
sysdiagnose(1) OS X Manual Page
Best Answer
Not a solution to the problem, but I found that closing the lid and waiting until the computer sleeps (status led pulsing) and opening it works. At least its better than a forced shutdown right?