"Your Computer Restarted Because of a Problem": What a Mac Kernel Panic Really Means

It arrives without warning. The screen dims to grey, everything stops, and a message appears in several languages at once telling you that your computer restarted because of a problem. Sometimes you click the button, the Mac comes back, and nothing like it happens again for a year. Sometimes it happens again that afternoon. And sometimes it happens during startup, over and over, until the Mac gives up and switches itself off.

This is one of the more alarming things a Mac does, partly because the message is so bare. It does not say what the problem was. It does not say whether the machine is dying. And when people go looking for an answer, the first page of search results is mostly software companies whose article ends with a download button for a cleaning app — which is a shame, because the honest answer is more interesting than that, and most of the time it is not a dying Mac.

There is also a genuine oddity here that is worth knowing about before you start reading anything. Apple has two support pages about this exact crash, and they do not tell you the same thing. One of them names the problem and then gives you two pieces of advice that do not apply to any Mac Apple currently supports. The other one is up to date and never uses the name at all — so if you search the words you actually saw, you may not find it. And neither page mentions the one thing on your Mac that can tell you what crashed it. That report exists, you can read it without any special software, and your Mac erases it a month after it is written.

So here is the whole thing in order: what the message means, the time-limited evidence to grab first, and then the architecture-correct version of each troubleshooting step — because a 2019 iMac and a 2024 MacBook Air need genuinely different instructions, and the page most people land on only covers the older one.

What the message means, and the word Apple uses for it on only one of its two pages

The crash has a proper name: a kernel panic. The kernel is the core of macOS, the part that talks directly to the hardware and that everything else depends on. If an ordinary app hits a fatal error, macOS can kill that app and carry on — that is the dialog telling you an app quit unexpectedly, which you have probably met at some point. But if the failure happens inside the kernel itself, there is nothing left running that could safely clean up, so macOS deliberately stops everything and restarts. The panic is not the fault; it is the safety mechanism reacting to the fault.

Apple's Mac User Guide puts it plainly: "If your Mac restarts unexpectedly, an error known as a kernel panic occurred, and a message indicates that your computer restarted because of a problem." That page goes on to name the two families of cause. "The most likely cause is faulty software." And: "A kernel panic can also be caused by damaged or incompatible hardware, including external devices attached to your Mac."

That is the useful framing, and it is the reason the troubleshooting has two separate halves rather than one list. You are trying to find out which of those two it is, and the fastest way to do that is not to start uninstalling things — it is to read what your Mac already wrote down.

Now the oddity. Apple's other page on this, the one titled "If your Mac restarted because of a problem" and last published on May 27, 2026, is the more current of the two — and the words "kernel" and "panic" do not appear on it anywhere. We checked the whole page for both, and for "RAM" and "PCI" as well: none of the four is present. It opens instead with "Unexpected restarts are usually caused by software installed on your Mac, or by devices connected to your Mac." That is perfectly good advice. But it means the term that describes what happened to you lives only on the older page, which matters, because "kernel panic" is the phrase that finds anything useful in a search, and the phrase a technician will use when you call.

One more line from that newer page is worth having, because it explains the worst version of this and nobody else seems to mention it: "If the issue causes your Mac to restart every time it attempts to start up, your Mac might eventually shut down." So a Mac that panics in a loop and then refuses to power back on has not necessarily taken a second, worse fault. Shutting down is what it is designed to do after enough failed attempts. That is a meaningful difference when you are deciding how frightened to be.

First, the only question that changes what you should do: once, or a pattern?

A single kernel panic, followed by weeks of normal use, is close to meaningless. Modern operating systems are enormously complex, cosmic-ray-grade bit flips are real, and a one-off panic with no repeat is not something we would ask anyone to spend money on. Note the date, get your backups in order if they are not already, and carry on.

A pattern is a different animal, and patterns come in types worth telling apart before you touch anything:

Panics that happen when you do a particular thing — open a specific app, plug in the dock, start a video call, begin a big file copy — are the most diagnosable of all, because you have already done the hard part. Write down the trigger. That single sentence is worth more than any amount of general cleaning.

Panics at random intervals while the Mac sits idle, or overnight, point more often at hardware or a background component: a driver, a security agent, a backup process, a failing external drive.

Panics during startup, every time, are the urgent version, and the one where you should be thinking about your data before your diagnosis. Skip ahead to the backup section.

And panics that started immediately after a specific event — a macOS update, a new app, a new peripheral, a memory upgrade on an older machine — have handed you the answer. The thing that changed is the suspect, and undoing it is the test.

The evidence expires in one month, so do this before anything else

This is the part that no one tells people, and it is the reason this article puts it before the troubleshooting rather than after.

When your Mac panics, it writes a report describing the state of the machine at the moment it stopped. That report is what makes a diagnosis possible instead of guesswork — it is the difference between "something crashed your Mac" and "this specific piece of non-Apple software was running in the kernel when it died." Apple's own page on Mac analytics lists exactly that among what your Mac records: "Details about app or system crashes, freezes, or kernel panics".

And then the same page says this: "Your Mac keeps analytics information for one month after it is generated, then deletes the information."

One month. So if your Mac panicked three times in the spring and once last week, the spring is gone and you have one record left. If it panicked last Tuesday and you decide to see whether it happens again before doing anything, you are on a clock you did not know you had started. Reading the report, or at least saving a copy of it, is the single highest-value thing you can do in the first few minutes — and it costs nothing and installs nothing.

It is also worth knowing that this is not conditional on having agreed to send anything to Apple. Apple's page is explicit: "Console shows analytics information even if you did not select to send reports automatically." Whether you share your diagnostics with Apple is a separate choice, made under the Apple menu at System Settings > Privacy & Security > Analytics & Improvements, where you can turn off Share Mac Analytics and Share with app developers independently. Turning sharing off does not stop your own Mac from recording the crash for you, and does not stop you reading it.

Where the report is, and what you are actually looking for

The app is Console, and it comes with every Mac — Applications > Utilities > Console, or search for it in Spotlight. No download, no purchase.

Down the left-hand sidebar are the report categories. Apple's Console guide describes the two that matter here: "Crash Reports: System and user reports about apps or processes that crash" — these carry a .ips extension — and "Diagnostic Reports: System and user reports with information about hardware resources, system response times, and more", whose names end in .diag or .dpsub. There is also a Mac Analytics Data entry in the sidebar, which is where Apple's own instructions point for viewing what your Mac has collected.

One practical catch that sends people away empty-handed: you need to be signed in as an administrator. In Apple's words, "If you're logged in as an administrator user, you can view all reports." If you are on a standard account you will see only your own user reports, and a kernel panic is a system-level event — so it will simply not be in the list, and it will look as though nothing was recorded.

Sort by date, find the entry whose timestamp matches the restart, and open it. It will be long, technical, and clearly not written for you, and that is fine, because you are not trying to debug it. You are scanning for one thing: a name that is not Apple's.

Apple's developer technical note on kernel panics explains why that works. The report includes a stack backtrace — "The backtrace is typically the most useful information in a panic log because it can be used to reconstruct the call chain that led to the exception" — and alongside it macOS prints the name and version of each kernel loadable module involved, a kernel loadable module being the working part of a kernel extension. In plain terms: the report lists the low-level add-ons that were in the picture when the machine died. If one of them is a VPN, an antivirus product, a virtualisation tool, an audio interface driver or a third-party disk utility, you have a strong suspect and a very short list of things to try.

Two honest caveats. If everything named in the report is Apple's own, that does not clear the software — it shifts the odds toward hardware or toward something in user space, and it means the peripheral and diagnostics steps below are where your time should go. And if you would rather not read it at all, that is a completely reasonable position: use File > Reveal in Finder from Console to get the actual file, copy it somewhere safe, and hand it to whoever helps you. The important thing is that the file leaves your Mac's one-month window before it is deleted.

If your Mac offers to move an app to the Trash, that is not a guess

Occasionally macOS works it out for you, and both of Apple's pages describe this. The newer one: "If your Mac suspects that a particular app caused the restart, it might ask whether you would like to move the app to the Trash." The Mac User Guide version adds what to do next — move the offending software to the Trash so it cannot go on causing panics.

Take the offer. But do the second half too, which is the half people skip: Apple's advice is to move it to the Trash and then contact the software developer to see whether an update is available. This matters because the app was very often not the problem in itself — it was an old version of the app whose low-level component stopped being compatible with your version of macOS. A current release frequently fixes it outright, and you get your software back. Deleting and never returning is the right move only if there is no fixed version.

The same logic covers the commonest single trigger we see in practice: panics that begin within a day or two of a macOS upgrade. Nothing has broken on your Mac. Something that was installed deep in the old version is no longer compatible with the new one, and the fix is an update from that vendor rather than anything you do to the Mac. Check for updates to every security, VPN, virtualisation, backup and audio product you run before you conclude anything worse.

The classic cause has largely been engineered out — and that changes the diagnosis

For most of the Mac's history, the stock answer to "what causes kernel panics?" was a third-party kernel extension, universally shortened to kext: a piece of non-Apple code loaded right inside the kernel, with the run of the whole system. Antivirus tools, VPN clients, virtualisation software, audio interfaces and disk utilities all used them, and when one was buggy or out of date it could take the machine down. Almost every article you will find on this subject is still written as though that is the situation.

It is largely not, and the difference is worth understanding, because it should change what you suspect. Apple has spent years moving that code out of the kernel. Since macOS 10.15, developers use system extensions instead, which run in user space. Apple's own deployment documentation draws the contrast: "In comparison to kernel extensions that inherently have full access to the entire operating system, system extensions running in user space are granted only the privileges necessary to perform their specified function. This approach helps to maintain the stability, integrity, and security of macOS." A modern VPN or security agent that fails is now much more likely to fail as an app than to take the kernel with it.

Apple has been blunt about the old way, too. The same documentation states that kernel extensions are no longer recommended for macOS "as they risk the integrity and reliability of the operating system", and that "Users should prefer solutions that don't require extending the kernel and use system extensions instead." Developers are pointed at frameworks such as DriverKit and NetworkExtension to build USB drivers, human interface drivers, endpoint security tools and network tools without touching the kernel at all.

Then there is the part that should genuinely reshape your suspicions on a recent Mac. Loading a kext is no longer something that can quietly happen. Apple's documentation: "Kernel extensions on a Mac with macOS 11 can't be loaded into the kernel on demand. They require administrator approval and a restart of the Mac. Additionally, they require that secure boot mode be set to Reduced Security." Changing to Reduced Security is a deliberate expedition — you shut the Mac down, hold the power button until "Loading startup options" appears, go into the Recovery app, open Startup Security Utility, authenticate as an administrator, and tick a box that Apple labels "Allow user management of kernel extensions from identified developers" and describes, in so many words, as allowing installation of software that uses legacy kernel extensions. Then you restart again.

Note Apple's own choice of word there: legacy. So on an Apple silicon Mac that has always run at full security, a third-party kext is not merely unlikely to be your culprit — it cannot have loaded at all. If you never made that trip into Recovery and never ticked that box, you can reasonably cross the entire classic explanation off your list and spend your time on peripherals, on an incompatible app in user space, or on hardware. That is a large saving, and it is the opposite of what most of the advice online will tell you to do.

Two of Apple's five suggestions describe a Mac that almost nobody now owns

This is where the older of Apple's two pages shows its age, and it is worth spelling out so you do not waste an afternoon on it.

The Mac User Guide's kernel panic page lists five things to try, and the fourth is: "Remove hardware upgrades from other manufacturers, such as random-access memory (RAM) and Peripheral Component Interconnect (PCI) cards." That was excellent advice for years. Third-party memory really is a classic cause of panics, and a bad stick can produce exactly this symptom.

But look at what macOS now runs on. Apple's compatibility page for macOS 27 Golden Gate, published September 14, 2026, is short and unambiguous: "If you have a Mac with Apple silicon, you can upgrade to macOS 27." Every model on that list — every MacBook Air and MacBook Pro, the MacBook Neo, every 24-inch iMac, every Mac mini and Mac Studio — uses memory that is part of the chip configuration you chose when you bought it. Apple's own tech specs describe it as unified memory, listed as a fixed amount that is "Configurable to" larger amounts at purchase. There is no stick to remove — not even on the Mac Pro (2023), whose own specification sheet lists 64GB of unified memory configurable to 128GB or 192GB. So the RAM half of that suggestion now applies to no Mac that can run macOS 27 at all. And of the whole compatibility list, exactly one model has PCI slots: again the Mac Pro (2023), which Apple specifies with six full-length PCI Express gen 4 slots plus a half-length gen 3 slot carrying its I/O card.

So on the overwhelming majority of Macs running a current macOS, one of Apple's five suggestions is physically impossible to carry out. That is not a criticism of the underlying advice — if you have an older Intel iMac, Mac Pro or mini with aftermarket memory in it, reseating or removing it is still one of the highest-yield things you can do, and if your panics began soon after a memory upgrade, start there and stop reading. It is simply that the page does not say which readers it is talking to, and a great many people arrive at it holding a laptop with nothing inside to open.

The practical translation, if your Mac is Apple silicon: read Apple's remove-third-party-hardware step as being about everything plugged into the outside of the machine, which is the next section, and let the internals go.

Safe mode, done for your Mac — plus the check that proves you are in it

Safe mode is the best single test in this whole list, because it starts macOS with third-party startup software held back. As Apple puts it, safe mode "can help you identify whether issues you're experiencing are caused by software that loads as your Mac starts up." If the Mac panics in normal use and is stable in safe mode, you have learned something concrete: look at software, not hardware.

The instructions differ by architecture, and this is the step where using the wrong ones wastes the most time. Apple's own way to tell which you have is to choose Apple menu > About This Mac and look at the label: an item called Chip means Apple silicon, an item called Processor followed by an Intel processor name means an Intel-based Mac.

On a Mac with Apple silicon: choose Apple menu > Shut Down and wait until the screen is black and any lights are off. Press and hold the power button until "Loading startup options" appears. Select your volume, then hold the Shift key and click Continue in Safe Mode. The Mac restarts by itself.

On an Intel-based Mac: turn it on or restart it and immediately hold the Shift key until the login window appears. You may be asked to log in twice.

Now the detail that is missing from nearly every other guide, and which we find matters because holding a key at startup often just silently does not work: you can verify it rather than hope. At the login window you should see "Safe Boot" in the menu bar. And for a definitive answer once you are logged in, hold the Option key, choose Apple menu > System Information, select Software in the sidebar, and read the item labelled Boot Mode. It says Safe if you are in safe mode and Normal if you are not. If it says Normal, the key press did not take and any conclusion you were about to draw would have been wrong.

While you are in safe mode, Apple's advice is to go to the App Store and install any available updates — which is often the whole fix, for the compatibility reason described earlier. Then restart normally and see whether the panics return.

Peripherals: the test most people run wrong

Apple names devices attached to your Mac as a cause on both of its pages, and in our experience this is the most under-weighted suspect of the lot — particularly docks and hubs, external drives and enclosures, audio interfaces, and anything that carries both data and power over one cable.

The method matters more than the idea, though, and Apple's newer page describes it properly. Shut the Mac down and disconnect everything; on a desktop, leave only the display, keyboard and mouse or trackpad. Then — this is the part that gets skipped — turn it on and use it for as long as it would normally take for an unexpected restart to happen. If your Mac panics roughly once a day, an hour of calm proves nothing at all. Give the test the same length of time as the symptom.

If the panics stop while everything is unplugged, reconnect one device at a time and keep testing after each one until the problem comes back. Tedious, and unambiguous. If the panics continue with nothing attached, you have cleared the peripherals and the next step is the hardware test below.

One addition from our own bench, offered as our experience rather than as anybody's documentation: include the cables and the power supply in your list of suspects, not just the devices. A marginal dock or a failing third-party charger can produce intermittent, apparently random crashes, and cables are the cheapest thing in the chain to swap out of the equation.

Apple Diagnostics — and what changed in macOS Tahoe 26

If software has been ruled out and the panics survive having everything unplugged, the next step is Apple's built-in hardware test, which checks components such as the logic board, memory and wireless parts. Again the keystrokes differ, and again this is from Apple's own instructions, last published on December 19, 2025.

Before you start: install any available macOS updates, shut the Mac down, disconnect external devices except keyboard, mouse, display, Ethernet if you use it, and AC power, and put the machine on a hard, flat, well-ventilated surface.

On a Mac with Apple silicon: press and hold the power button — the Touch ID button on laptops that have one — and keep holding as the Mac turns on and loads startup options. When you see Options, release the power button, then press and hold Command-D until the Mac restarts.

On an Intel-based Mac: turn it on and immediately hold the D key. If that does not work, hold Option-D instead.

There is a recent change here that is easy to trip over if you are following an older guide, and Apple flags it: "In macOS Tahoe 26 and later, you're asked to choose a specific diagnostic to run, such as a diagnostic for your built-in display, keyboard, or trackpad. In earlier versions of macOS, this is automatic." So if you were expecting one test to run by itself and instead you are looking at a menu, nothing is wrong — you are on a current macOS and you now pick what to test. For an unexplained panic, memory is the test to reach for first.

Apple Diagnostics needs a network connection, or will offer to run offline if you have not been sent an online session by a support technician. When it finishes it may give you one or more reference codes, and those are worth writing down exactly: they are what an Apple Store, an Apple Authorised Service Provider or an independent repair provider will ask for, and they turn a vague "it keeps restarting" into a specific component.

Worth being straight about the limits, though. Apple Diagnostics passing is good news but not proof of innocence — intermittent memory and power faults can pass a short test and still crash a machine under load. A clean result plus a continuing pattern of panics is a reason to keep going, not a reason to stop.

Reinstalling macOS: when it is the right call

Both of Apple's pages end at the same place, and so do we: if the software checks and the hardware checks have not resolved it, reinstall macOS. It is less drastic than it sounds — a reinstall replaces the operating system and leaves your files and apps in place — and it resolves the class of problem where something in the system itself has been damaged or modified.

The Mac User Guide adds one specific case where it is not optional but required, and it is worth quoting because it is the kind of thing people try to shortcut: "If you moved or renamed a system file or folder, you must reinstall macOS—it won't work to just replace or rename the item." If you have ever gone digging in the System or Library folders and relocated something, that is your answer, and putting it back will not do.

Do not reinstall as step one, though. It costs hours, and if the cause is a failing stick of memory or a dying external drive, you will do all of it and then watch the same grey screen appear again.

Back up first — and on a Mac that panics at startup, back up before anything

Everything above assumes you can afford to experiment. That assumption holds only if your files exist in a second place.

A kernel panic is usually a software or peripheral problem and your data is in no danger. But the two causes we most want to rule out — failing memory and a failing drive — are both capable of corrupting things quietly while you troubleshoot, and a Mac that panics repeatedly during startup may be a Mac you get a limited number of further chances to copy files off. If your backups are current, this whole article is a puzzle to work through. If they are not, it is a race, and the order changes: get a copy of your important files onto an external drive or into cloud storage before you start pulling hardware or reinstalling anything.

If the Mac will not stay up long enough to copy anything, that is the point to stop and ask for help rather than to keep restarting it hopefully. Repeated crash-and-reboot cycles are not a neutral act on a machine with a marginal drive.

A word about what else you will find in the search results

Search this message and you will be offered a great many cleaning and optimisation apps, each with an article explaining that kernel panics come from junk files, caches or clutter, and a download link. We will be plain, as we are elsewhere on this site about Mac cleaners: that is not what causes a kernel panic. A panic is a fatal error inside the kernel, and cache files do not cause one. Some of those products are legitimate software with genuinely useful features; none of them is the answer to this question, and installing a low-level utility on a machine that is already crashing at a low level is a poor trade.

The actual diagnostic tools for this are the ones already on your Mac, and they are free: the panic report in Console, safe mode, disconnecting peripherals, and Apple Diagnostics. That is the whole toolkit, and it is the same one we use.

The short version

Grab the evidence first, because it expires — open Console, find the report matching the restart, and save a copy. You have one month from the crash.

Establish whether it is one panic or a pattern, and write down the trigger if there is one. A single panic with no repeat needs nothing but a good backup.

Update everything, especially security, VPN, virtualisation, backup and audio software, and above all if the panics started after a macOS upgrade. If your Mac offers to move an app to the Trash, accept, then ask that developer for a current version.

Test in safe mode, and verify you are actually in it via System Information > Software > Boot Mode.

Disconnect every peripheral and then run the Mac for as long as it normally takes to crash — not five minutes. Reconnect one at a time.

Run Apple Diagnostics and write down any reference code exactly.

Reinstall macOS if the rest has not resolved it. And if your Mac has aftermarket memory in it, deal with that before any of the above.

How we can help

We look after Macs and PCs for households and small businesses across Southern California and the Coachella Valley, onsite or by remote support. A Mac that panics intermittently is one of the more satisfying things to be handed, because the machine has usually already written down what went wrong — the work is reading the report, matching it against what is installed, and testing the suspect properly rather than replacing parts hopefully.

If yours has restarted because of a problem more than once, the useful first move costs you nothing: open Console and save the report before the month runs out, and note the date and what you were doing. Bring us that and we can usually tell you quite quickly whether you are looking at an out-of-date piece of software, a peripheral, or something that needs a hardware repair. Because we do not sell computers or software, there is nothing we are steering you toward.