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
First thing is, after a reboot, to look at /var/log/system.log
.
Search from the end for BOOT_TIME
. This is the first entry after your mac reboots. Now go up to read the lines above. This might give you a clue what happened right before the mac had frozen.
To take a look at more logfiles, go to /var/log
and list them with
ls -ltr
This will sort them by time so that newest files are at the bottom.
If you can't find something helpful inside system.log
you might have a chance when looking at the logs that have been written around freeze time (or later).
Best Answer
This is a common Flash interaction issue (sounds like). I use the Safari extension ClickToFlash so I can control what Flash runs and when. And, I also use AdBlock to be sure those pesky side Ads don't bother me. You can still run Flash, but you have control and the freezing will hopefully stop.