Finder keeps crashing on a Mac, and how to find the file or plugin behind it

A Finder that crashes once is an annoyance. A Finder that crashes several times a day changes how the Mac is used: folders get avoided, the desktop gets emptied out of superstition, and work moves into whatever app will open a file directly. Relaunching becomes a reflex.

Repeated crashes almost always have one specific cause, and that cause usually leaves a trace. There are three places it typically hides: a single file that Finder cannot process, code from another app that runs inside Finder, or damaged settings and caches. This article works through finding which one it is, starting with the evidence the Mac has already collected.

Read the crash report first

Every crash writes a report, and the report names the code that was running at the moment of the crash. This is faster than any amount of trial and error.

Open Console from Spotlight and select Crash Reports in the sidebar. Apple's guide describes what is there:

Crash Reports: System and user reports about apps or processes that crash. Crash report names have the .ips extension. Source: support.apple.com

Look for reports whose names begin with Finder and whose timestamps match the crashes. The same files can be reached in the Library folder for the user, under Logs and then DiagnosticReports.

A crash report is long, but only two parts matter here.

The termination reason near the top says what kind of failure it was. A crash caused by bad data in a file usually looks different from one caused by a hang, and a report that mentions a timeout points at something slow rather than something broken.

The crashed thread's stack is the list underneath. Read it from the top down and look for a name that does not belong to Apple. Entries referring to a bundle from another developer, for example a cloud storage suite, a compression tool or a file tagging utility, point straight at that product. Entries mentioning preview or thumbnail generation point at a file rather than an app.

If several reports name the same non-Apple component, the investigation is effectively over. Update or remove that app and the crashes usually stop.

Narrow it to a folder, then to a file

When the reports point at previews or thumbnails, or when there is no obvious third-party name, the cause is likely a single item that Finder chokes on while drawing a window. Media files with damaged headers, files copied from a failing drive, and files whose extension does not match their contents are all common triggers.

The search is a straightforward split.

1. Note which folder is open when Finder crashes. If crashes only happen in one place, that folder holds the cause.
2. Switch that folder to list view with Command and 2, and turn off previews. In View Options, opened with Command and J, clear the icon preview option and the preview column. Finder then draws the window without generating images. If the crashes stop, a file's preview is the trigger.
3. Split the folder in half. Move half the items to a new temporary folder, open the original, and see whether it still crashes. Whichever half crashes holds the file. Repeat until one file is left.
4. Once found, move that file out of the way. Opening it in the app that created it, or converting it, often reveals that it is damaged.

The same split works from Terminal, which never touches previews at all. Listing a folder with ls -l shows the items without asking Finder to draw anything, and mv moves them out in batches. When Finder crashes on a folder that cannot be opened at all, Terminal is the only practical way to work through it.

Two folders deserve special attention because they collect files from everywhere and are always open: the Desktop and Downloads. A crash that happens right after login, before any folder is opened by hand, usually involves the Desktop, since Finder draws it immediately.

Turn off Finder extensions

Code from other apps runs inside Finder. Cloud storage clients, version control tools, backup utilities and tagging apps add badges, menus and sync state to Finder windows through extensions. When one of them fails, Finder fails with it, and the pattern is often erratic: crashes when a synced folder is opened, or when a contextual menu is used.

Apple places the switches in System Settings, under General, then Login Items & Extensions. Third-party extensions are listed there, and a Finder checkbox appears for those that extend Finder.

The method is mechanical. Turn all of them off, use the Mac normally for a while, and see whether the crashes stop. If they do, turn them back on one at a time, leaving a day or an hour between each depending on how often crashes occur. The one that brings the crashes back is the cause. Its developer's release notes often already mention a fix in a newer version.

Login items matter too. Apps that start at login and watch the file system can crash Finder indirectly by holding resources it needs. The same settings panel lists them, along with a switch for background activity by installed apps.

One detail saves time here. Turning an extension off does not always stop the app behind it from running, and some suites keep a helper active that reaches into Finder anyway. When switching the extension off changes nothing, quit the app from its menu bar icon and check Activity Monitor for any helper process bearing its name before concluding that it is innocent.

Reset previews and thumbnails before blaming a file

Previews are generated by a separate service, and its cache can hold a broken entry long after the file that produced it has gone. That produces a crash that follows no obvious file, because the item being drawn no longer exists in the folder.

Two commands in Terminal clear it. The first reloads the preview service, and the second empties its thumbnail cache:

qlmanage -r
qlmanage -r cache

Finder picks up the change without any further step, although relaunching it with killall Finder makes the result easier to judge. If crashes in a folder full of images or videos stop after this, the cause was the cache rather than a file.

Older preview plugins are the other half of this story. Some apps install their own preview handlers so that their document types can be previewed in Finder. A handler written for an earlier version of macOS can fail on a current one. These plugins live in the Library folders, in a directory named QuickLook, both at the top level of the startup disk and inside the user Library. Moving the contents of those directories to the desktop, then running qlmanage -r, disables them without removing anything permanently. If the crashes stop, put them back one at a time to find the offender.

Use safe mode to split the problem in two

If the crash reports were unclear and switching extensions off changed nothing, safe mode gives a definite answer about which side of the line the cause is on. Apple describes what it does:

Prevents certain software from loading as your Mac starts up. This includes login items and extensions that aren't required by macOS, and fonts that weren't installed by macOS. Source: support.apple.com

Fonts are worth noticing in that list. A damaged font can crash apps that draw text, and Finder draws a great deal of text. If Finder is stable in safe mode but crashes normally, and no extension turns out to be responsible, open Font Book and use its validation feature on recently installed fonts.

Safe mode also performs a basic check of the startup disk and clears some system caches, which means a problem that disappears after one safe mode start and does not return was probably a damaged cache rather than an app.

If Finder crashes in safe mode as well, third-party software is not the cause. The remaining candidates are the account's own settings, the disk, and macOS itself.

Rule out settings, space and the disk

Three checks cover what is left, in order of effort.

Account settings. Create a second user account in System Settings, under Users & Groups, and use Finder there. If it never crashes in the new account, the cause is in the original account's preferences or sidebar list. Export the preferences first with defaults export com.apple.finder ~/Desktop/finder-backup.plist, then clear them with defaults delete com.apple.finder and killall Finder.

Free space. A nearly full startup disk causes crashes that look random, because apps cannot write the temporary files they expect. In Terminal, df -h / shows what is available. If only a few gigabytes remain, free space before investigating anything else.

The disk itself. Run First Aid on the startup disk in Disk Utility. File system damage produces exactly the pattern being described here: a specific folder that crashes Finder every time, with no third-party software involved. If First Aid reports errors it cannot repair, back up immediately and treat the disk as unreliable.

Installing pending macOS updates belongs in this group as well. Apple's own guidance for apps that quit unexpectedly puts software updates among the first things to check, because the fix for a known crash often already exists.

Stop relaunching and start recording

Repeated crashes are easier to solve with two minutes of record keeping than with another hour of guessing. Keep a short note of each crash: the time, the folder that was open, what had just been done, and whether a device or network share was connected. Three or four entries usually make the pattern obvious, and they make the crash reports far easier to read, because the right report can be picked out by timestamp.

The notes also settle a question that comes up often: whether Finder is crashing or merely being relaunched by a well meant utility. Some cleanup and optimization apps restart Finder on their own schedule. If the "crashes" line up with those tools running, the fix is to change their settings rather than to hunt for a damaged file.

For people whose crashes cluster around one heavily used project folder, there is a practical workaround while the cause is being tracked down: work in that folder somewhere other than Finder. Terminal never draws previews, and a file manager with a built-in terminal shows the folder, the command line and an AI assistant in one window, which keeps work moving without Finder in the path. The features page describes that arrangement, and pricing covers what it costs.

What to change first

Open Console and read the most recent Finder crash report before doing anything else, since a non-Apple name in the crashed thread ends the search immediately. If the report points at previews, switch the folder to list view without icon previews and split it in half until one file is left. If crashes continue with all third-party extensions off and in safe mode, move on to disk space and First Aid. While the cause is being found, Atriens gives a way to keep working in the same folders with folders, a terminal and AI in one window.