MacOS – Can’t restart Mac: Finder not responding or «not open anymore» & other culprits

finderforce quitmacosrestartshutdown

First-timer here.

I have been experiencing several serious-looking problems with my MacBook (OSX Yosemite 10.10.5, model MacBookPro10,1: Mid 2012 Retina, 16GB RAM, 768GB SSD) for a while now, the major of them being unable to restart, shutdown or log out normally. What happens is, after quitting every app, the system is left idling at the empty desktop — no icons, no menu bar, just the wallpaper. The mouse pointer is movable, Dock and Spotlight are still operating, but Finder is «Not Responding» and unable to relaunch in any way. So all I'm left with is a hard Power button reset or sudo shutdown -h now (another workaround is to click Restart with admin rights on the login window, I presume it's the same as the terminal command).

This problem is accompanied (and may or may not be caused) by many others:

Certain apps may refuse to quit against all measures as well, thereby hanging out in the Dock and halting the shutdown
Quick Preview (handy Spacebar thing) is showing nothing but empty white rectangles
Preview itself opening all files as empty windows or practicing other weird behaviours like not showing the pixel selection frame
Finder throwing up a self-conscious «The application “Finder.app” is not open anymore» in response to launching apps or opening windows through Spotlight (even though ⌘-Enter to show file location still works)
Folders appear to be empty until Finder is relaunched (manually or by itself)
Unable to launch some apps, notably Photos
Minor rare cases of graphics corruptions, like garbled windows in Mission Control

All of these get fixed by a Mac restart, but keep steadily accumulating again. It's like the more time elapses after a restart, the more ruined and deteriorated the system becomes.

What I tried:

Resetting NVRAM
Resetting the SMC
Performing an extended Apple Hardware Test (no issues were found)
Verifying hard drive and repairing disk permissions
Booting in Safe Mode (where everything gets super slow; the problem persists)

For a positive note, this whole situation has taught me to do frequent Time Machine backups, but I would like to leave OS reinstallation as a last resort. (My drive is partitioned into two, with Windows 7 installed through Boot Camp, if that has significance.) I know that Yosemite is quite old, but I'm honestly scared of upgrading lest it becomes worse (performance loss, new glitches, feel free to reassure me).

So, could anyone provide tips on what the root of this problem may be and how to fix it? Logs I should check, tests I can do, files to wipe or redact? Any advice is appreciated. Thank you, and safe travels!

Update 1:
I have tried booting into Safe Mode once again, acting out some generic work and having a look at the Activity Monitor. Here is what it looks like:

Interestingly, the computer seems to shut down properly from Safe Mode. Once again though, some window animations are extremely slow to render here, producing beautiful scrolling lines.

Then, I booted normally and did roughly the same manipulations. The Monitor from here:

I also tried shutting down in normal mode immediately after landing on the desktop after a restart, which works. So one can assume there is a software gimmick that is causing this problem shortly after startup.

Update 2:
I created a new Standard (non-Admin) account as was suggested, and I think that helped to uncover the exact criminal in disguise — Finder. It seems like everything works nicely (while launching and switching apps), until the first Finder window is open (any folder), which somehow makes Finder unresponsive on shutdown, thereby freezing the latter. This happens on both user accounts. Interestingly, switching to another user and doing a «proper» shutdown (from Apple menu) before using Finder is working (although I guess the «blocked» user's session is still halted abruptly and incorrectly then).

Now, the question is: what exactly is wrong with Finder, and how can I help the little guy?

Update 3:
As suggested, I tried moving Finder cache and preference files to desktop through the Terminal while logged in as a different user, but this doesn't seem to affect the problem.

I could find no crash logs for Finder apart from some short diagnostic reports, and noticed nothing unusual displayed by the Console while the faulty shutdown is in process, but here is an example of some fishy Finder-related events which may be happening during uptime:

(I do not know how significant these are; the Console spits out things like that from various processes regularly).

Best Answer

Here's what I would try:

Login as your 'other' user.
Launch Terminal.app
Type login shortname (where shortname is the username that is having problems with Finder) and enter your password when prompted. (Then type whoami to verify you are logged in the correct account.)

Run these commands:

mv -v ~/Library/Caches/com.apple.finder/ ~/Desktop/

mv -v ~/Library/Preferences/com.apple.finder.plist ~/Desktop/

Log out as your 'other' user.
Log in as shortname as usual.

All of your Finder preferences will be reset to the defaults, but it might solve your problem.

Observe verbose mode during restart or shut down

Mac OS X: How to start up in single-user or verbose mode

– if you start in verbose mode, then restart or shut down will be similarly verbose.

Hint: if things in verbose mode seem to not progress beyond a certain point, allow maybe five minutes before either:

forcing a restart (Command-Control-power); or
forcing a shutdown (press and hold the power key).

If a forced restart does not succeed, that could be another clue to the cause of the problem(s).

A related question, albeit not problem-oriented: Can anyone interpret verbose shutdown messages?

The problem-oriented case here should be easier to resolve for lupincho. Fewer tea leaves.

To start in verbose mode without keying Command-V

A preference can be stored in NVRAM. Enter the following command in Terminal, and be prepared to enter your admin password:

sudo nvram boot-args="-v"

The next start of the system will be verbose.

sysdiagnose

Before each restart or shutdown, in Terminal:

sudo sysdiagnose

It's time consuming, but you need not investigate the results of all runs. Pay attention only if a problems arises.

For a case such as lupincho's:

the run of sysdiagnose may reveal a problem before a restart or shut down
the end result of sysdiagnose may be of interest following a forced restart or shut down.

More specifically: if a run of sysdiagnose fails to progress beyond a certain point, knowing that point can help to gain a sense of the underlying problem.

During the run you can use the following key combination, repeatedly, to see whether things are progressing:

Control-T

For the allmemory part of the sysdiagnose routine, Apple's two minute estimate may be wildly inaccurate. Be patient.

If you suspect that sysdiagnose fails to progress beyond a certain point, then key:

Control-C

If repeated use of Control-C fails to abort sysdiagnose, then (in my experience with Mountain Lion) it's almost certain that an attempt to restart or shut down the operating system will fail.

Shutdown monitoring

In Finder, go to:

/private/var/log/shutdown_monitor.log

This file is typically empty, but may contain items of interest following a problematic shutdown. (I have little experience in this area.)

If the only stray process at shutdown is WindowServer

It's not unusual to have stray processes at shutdown. A stray can be problematic only if it is not killed.

If you suspect that WindowServer is not killed, and that this particular stray is contributory to shutdown failure: ask yourself whether any third party software makes nonstandard use of the WindowServer process.

Quick Look of a GrabFS view of WindowServer on Mountain Lion, with two displays:

enter image description here

If Lion is similar, then my gut feeling is that the cause of shutdown failures lies beyond WindowServer.

Guesswork, based upon results of launchctl

Whilst the machine is running normally, what response to the following command?

sudo launchctl list | grep  --invert-match com.apple

Wonder whether any non-Apple software is contributory to the problem. Anti-virus, anti-malware software?

Following an upgrade from Lion to Mountain Lion

Aim for:

/private/var/log/com.apple.launchd/launchd-shutdown.system.log

It seems the default is one log per shut down, with a maximum of two so there's also:

/private/var/log/com.apple.launchd/launchd-shutdown.system.log.1

Following any forced restart or forced shut down, you might choose to set aside a copy of the most recent of the two. If force is required on any more than one occasion, you can compare files to see whether a pattern emerges.

Generally

Don't rule out the possibility of an issue with third party software, even release quality. Little Snitch may be well written and widely respected but:

when problems such as the one in this question become extended or too puzzling, any non-Apple kernel extension deserves attention.

I tested Build 12A269 of OS X 10.8 for around two weeks before it was released, with particular attention to shut down behaviours in difficult situations. Whilst I have not watched any videos from WWDC 2012, I do have a sense that Apple has worked very hard to prevent the need for force in all but the most difficult situations.

Building upon David DelMonte's answer

At least on Mountain Lion, I see the load of Little Snitch 3.0 Preview 2 (3857) very early – before shutdown logging begins. If things relating to this KEXT are similarly late around shutdown time, then maybe an issue will be not evident in the usual log files on disk.

If ever you discover the cause of the problem – with either Lion or Mountain Lion – I'll be pleased to know.

In the meantime, with big thanks for the bounty, a closing thought:

kextstat -l | grep --invert-match com.apple

Mac does not restart, shutsdown instead

Since you didn't list enough technical details about how file vault is set up (for instance if you have auto log in enabled or disabled, whether you are using institutional keys or just having one or more users storing the unlocking keys in the user accounts so that the recovery HD can unlock things) - I'll start with some steps to narrow down what might be happening.

First thing is to check if the machines are capable of restarting by storing the file vault key in RAM:

fdesetup supportsauthrestart

If that reports "false" then your hardware might not support restarts with FileVault 2 enabled. If it's true, does the system reboot if you ask for a controlled restart?

fdesetup authrestart

Also, if you're not comfortable with the fdesetup tool, you might want to review some of the helpful articles from Rich Trouton's blog. You'll want to start with an old article getting the basics covered if the current articles assume too much knowledge of how fdesetup works as dealing with file vault from the command line is a lot like the proverbial "sip of water from a fire hose" to many.