About Press Copyright Contact us Creators Advertise Developers Terms Privacy Policy & Safety How YouTube works Test new features Press Copyright Contact us Creators. Kernel Panic, though sounding scary, is simply an occurrence when your Mac keeps restarting for no obvious reason. Your Mac’s screen goes black, giving you various warning messages like “You need to restart your computer.” Note that the warning message's presence distinguishes Kernel Panic from usual Mac restarts and app crashes. Kernel panics usually generate a file called a panic log. The structure and location of this file depends on the version of Mac OS X you are using: Under Mac OS X 10.6, panic logs are saved in the Macintosh HD Library DiagnosticReports folder.

• Souls Panic Mac Os Catalina
• Mac Os Catalina
• Souls Panic Mac Os Download
• Souls Panic Mac Os X Screensaver

One of the scariest things any Mac user can experience is kernel panic: that moment when you are staring at a darkened display wondering what to do next. The answer is quite simple: don't panic – your machine did that for you already.

What Is Kernel Panic?

If you see a darkened display with the message “You need to restart your computer. Hold down the power button until it turns off” or your Mac becomes unresponsive, spontaneously restarts, and then displays a message that the computer restarted because of a problem, it's a clear sign that the OS X or macOS kernel detected an unrecoverable error. It’s termed as ‘unrecoverable’ because the heart of the operating system, the kernel, can't handle whatever the problem is and loses control.

Download CleanMyMac X from MacPaw’s website and clean up to 500MB of junk data from your computer while enjoying all the features of the software without major limitations.

In this situation, the kernel pushes the panic button – in fact, it runs the panic function code – doing what it can to protect the system. In doing this it collects some data on the current condition of the processors, the running processes, and it either displays a warning message prompting a shutdown (OS X Lion or earlier) or just restarts the system. Unfortunately, everything you were working on is gone if you couldn’t save it before the kernel panic.

With OS X Mountain Lion, Apple changed the design of the panic function so that it restarts the Mac first and then displays the following message: “Your computer restarted because of a problem. Press a key or wait a few seconds to continue starting up.”

What Causes Kernel Panic?

In most cases, kernel panic is not caused by the Mac itself but by faulty software or hardware. It is recommended that you always run the latest software, because that will help eliminate the likelihood of kernel panic occurring.

Still, if the machine panics like this again, it's certainly time to start troubleshooting, so first investigate what is causing the error. Unfortunately, discovering recurring kernel panics is a bit harder with older versions of OS X because you need to have the same conditions in place to identify the root cause. That changed with OS X Mountain Lion: now your operating system saves a log of which apps and background processes were running at the time of the kernel panic and, upon restart, offers to launch all the apps and processes that were running before the error.

How to Fix Kernel Panic

As mentioned above, kernel panic is caused by problems with either software or hardware, so the first step is to identify which it is that is responsible.

After the system has restarted, the operating system gives the option to report the problem to Apple so the company can investigate the incident, but the report is a good resource for you to check whether it is a software or hardware issue, too. Locate the term ‘machine check’ in the Problem Details and System Configuration field of this report, here it may indicate whether it was a hardware-related issue.

If for some reason the dialog box was dismissed, the log can be found within the Console app at this location: Library/Logs/DiagnosticReports.

If the issue is related to software, OS X Mavericks will help you correct it by offering to disable the faulty app. It will display a dialog box informing you about the problem caused by whichever application it was and ask you whether you want to move this app to Trash.

The “More Info” option here will display more details and possible workarounds to solve the issue, while the “Ignore” button will keep the app intact. Clicking on the “Move to Trash” button will display another prompt informing you that a restart is needed to solve the problem.

These are just the basic steps that the operating system offers to fix kernel panic, and in most cases this will be sufficient. Recurring kernel panic, however, is a different animal entirely, and dealing with it requires some advanced knowledge, so it may be best to ask for help from an Apple Authorized Service Provider or a Genius at an Apple Store. Before doing that, however, check out our guide on how to isolate the problem to a hardware or software issue, and the steps to take to fix the problem.

Best Mac Optimization Software of 2021

Get the Best Deals on Mac Optimization Software

Stay up to date on the latest tech news and discounts on Mac optimization software with our monthly newsletter.

I give up. After upgrading to OS X 10.9.3, I've experienced the least reliable computer of my life. I've had 16 kernel panics in 4 days, usually when plugging in remote displays, but sometimes just spontaneously.

In a meeting yesterday, a coworker exclaimed how reliable and awesome 10.9.3 was, and that he didn't have any kernel panics at all. I fantasized that his macbook spontaneously panic'd as he said that, proving him wrong in theatrical fashion, preferably with a loud bang and smoke. (It would also show that it wasn't just me.)

I settled for some debugging to see why his macbook was different, but he shooed me away from his keyboard as he was about to do an IMPORTANT DEMO, and didn't want me to jinx it. He plugged in a data projector.

Instant kernel panic.

He was now the third co-worker to experience this after upgrading to 10.9.3.

tl;dr: Jump to Update 8 for the workaround.

OS X saves diagnostic reports for each panic in /Library/Logs/DiagnosticReports. Note the dates:

These can be useful to browse for patterns. Maybe it's just one application which I can stop using?

No, it's completely random. This looks a lot like bad or misseated DRAM, so our helpdesk performed what they called a 'shell swap'. This means they replace everything except the SSD. Or put differently, they take out the SSD and put it in a 'known to be good' macbook pro, to see if the panics continue.

They continued.

Here's an example report:

So, CR2 (0x000000000000007a) looks bogus, leading to the panic. I can't infer much more than that, since I'm missing kernel symbols, and the stack trace is hex.

It would be nice if the kernel wasn't stripped, or, if it was easier to get the Kernel Debug Kit (please put them on opensource.apple.com). I'd help debug this further, but can't without symbols (at least, easily).

A few of us are now have the recurring 10.9.3 panics. After sending Apple many diagnostic reports with additional details, I'm switching back to 10.9.2. 10.9.3 is toxic with remote displays.

A coworker suggested the fix.

While I hope Apple fix this in 10.9.4, I'm now leery of OS X updates. I'd feel a lot better if I could debug this on my own further.

I should add that I've used Apple products and OS X for many years, and have been impressed by the reliability and quality of their work. 10.9.2 on the same laptop worked fine, and I'd have prior OS X releases with hundreds of days of uptime. I'd still recommend their products, as I hope this experience was an outlier.

Update 1

Symbols for this stack below (thanks Rasmus!)

Update 2

Based on the hackernews comments, some people have hit this and others haven't, and using external displays is a factor. Some have said that they have had issues with 10.9.2 as well, or all the 10.9 series. Perhaps it is a problem with a particular graphics card driver (myself and my coworkers have the retina Macbook Pros), but that's just a guess. The decoded stack above includes HFS calls, but that makes no sense, unless the graphics driver was stepping on random memory (which are among the worst panics to debug).

EDIT: After learning that this doesn't affect everyone, I changed the title of this post from 'Is Toxic' to 'Recurring Panics'. I also removed the words 'infected' and 'disease', which were off-putting.

Update 3

I got another new macbook pro, running 10.9.2 (although, a different kernel version), and switched using migration assistant. It worked great, initially. Then I had five panics in a row when connecting to different remote displays. In case migration assistant moved over some corrupted preferences, I got another new macbook pro, with 10.9.2, and just began using it fresh, and was still able to reproduce the panics (running only Firefox and Chrome, this time). I don't know if these panics are the same as what I had on 10.9.3, since I only have hex dumps to compare. 10.9.3 seemed to panic much more easily.

I'm a little fed up of the typical macbook debugging technique: switch things until the problem goes away. I'm also fed up with seeing stack traces that are inscruitable hex. I want to read the stack traces, and understand what the kernel is doing that led to the panic. So I studied how Rasmus had translated my earlier stack, and I learned that the default kernel (mach_kernel) does have some symbols, which aren't used in the diagnostic reports. Excellent. I can write a quick helper tool for translating stacks.

Update 4

I wrote kernel_diagreport2text.ksh, a tool that translates symbols from OS X kernel diagnostic reports using two different techniques. It is here on github.

Here's my new 10.9.2 macbook panics, summarized by kernel_diagreport2text.ksh:

I wish I had this tool earlier! It uses atos(1) for symbol translation, and decorates remaining addresses with kernel extension names (eg, 'in com.apple.driver.AppleUSBHub') if available in the diag report. It does not need the Kernel Debug Kit installed, although if it is, you should get more symbols translated.

That output is for a default 10.9.2 system, and while many symbols are missing, we can still learn a lot. All of these panics are in VM, and don't look the same as the 10.9.3 panic that was translated earlier.

To run this yourself, download (or save) the raw script. Then open up Terminal (which is under Applications->Utilities) for a command line, and you can run it on your saved kernel diagnostic reports. The steps are likely something like this (depends where your browser has downloaded the file):

This script is (obviously) not an official Apple diagnostic tool, and is provided as-is with no warranties or guarantees. It does not need to be run as root.

Update 5

29-May-2014. I've partially translated my 10.9.3 panics, using my kernel_diagreport2text.ksh tool described earlier. Here are some key examples:

The others showed similar stacks. These are also all in VM, either page faults or an explicit panic() call in the VM_PAGE_QUEUES_REMOVE macro.

To translate my 10.9.3 diag reports with the kernel_diagreport2text.ksh script, I needed a copy of the 10.9.3 mach_kernel (I'm back on 10.9.2), and to edit the script to point to it (update: that's now the -f option). Apple's auto update had already downloaded the 10.9.3 update, putting it in /Library/Updates/031-02348/OSXUpd10.9.3.pkg. That pkg file turned out to be Russian dolls: a xar, containing a bzip2 file, containing a cpio archive, which contained the 10.9.3 mach_kernel.

If you ever want to do something similar yourself, you really want to make sure the mach_kernel matches what you have in the diag report, otherwise the translations will be incorrect. Eg:

Those match! The source for xnu-2422.100.13 isn't out yet, but when it is, it should be under opensource.apple.com/source/xnu. I've been browsing the earlier version to get a handle on the VM code.

Update 6

After a quick browse of the VM code, it looks like a double free, based on the VM_PAGE_QUEUES_REMOVE panic. It's possible the other VM panics are manifestations of the same bug. These are nasty bugs to debug, as the engineer must track down the earlier free. This is harder than it sounds, as free's occur so frequently. I could run out of memory trying to log them for later lookup.

But after using DTrace on the vm_page_free_prepare_queues path, I'm not sure it's a double free using the vm_* interface, as mem->free was not set. Which suggests something even nastier – someone else is stepping on memory, perhaps zero'ing it out. Now if two paths are fighting over the same memory, and if I'm lucky, they do so in either order with the 2nd hitting the panic. Which could mean I've already captured both paths in the earlier panics. The IOBufferMemoryDescriptor::free() could be the non-VM path that's freeing memory, coming from IOAcceleratorFamily2.

Souls Panic Mac Os Catalina

This is just speculation - I don't know what the real cause is yet. But given the nature of the panics (external displays), the partially-translated stacks, the open source xnu kernel, and DTrace to test theories, I have a lot of clues. The hardest part is finding time to put into this.

Mac Os Catalina

Update 7

Here's an older panic excerpt (OS X 10.5.8):

Notice something? This has arguments for the stack functions, which are incredibly useful when doing panic analysis, especially when all we have to go on is the panic report file. So where did these args go in 10.9?

From the xnu-2422.90.20 source, osfmk/i386/AT386/model_dep.c:

PRINT_ARGS_FROM_STACK_FRAME needs to be set. It's set in the same file:

(shakes fist.) No comment, no explanation, just zero that guy. Why?

I think the reason can be explained by an earlier kernel version, xnu-2050.9.2:

Ah. Stack frame arguments are architecture specific, and the code was written for i386, but not x86.

It should be a fairly easy enhancement for Apple to add the x86 code, and greately enhance all kernel panic reports.

Update 8

30-May-2014. I have a workaround in hand for Mavericks 10.9.2: turn off Firefox hardware acceleration. With this off, my panics have now stopped. Perhaps this works on 10.9.3 as well, if it is the same panic. The setting is under Preferences->Advanced->General.

Other applications use hardware acceleration as well, so you may need to disable it elsewhere, if you believe you have this bug. For me, the easiest way to duplicate the panic was to run a youtube video full screen in Firefox, then plug in a remote display, and close the laptop lid. A few cycles of that usually led to the same type of panic I was hitting earlier. And with hardware acceleration disabled, it worked fine.

I still feel this was much worse in 10.9.3 (if I had more time, I'd confirm). The 10.9.3 update did say that it 'Improves 4K display support', which may have modified the hardware acceleration routines.

Souls Panic Mac Os Download

I suspect hardware acceleration was freeing or stepping on memory it shouldn't, which led to the VM panics. I'd like to write more about this, including where I was in the analysis, and ideally identify the root cause, but now that I have a workaround it's no longer a priority to work on. I may do a follow up blog post later when I have the time. I wanted to share the workaround ASAP.

Souls Panic Mac Os X Screensaver

This information has been filed as Apple bug ID 17082120. (This is in addition to the 30 or so Kernel diag reports I've sent their way.)