Right now there is not so much you can do, except to do a hard restart or shutdown the computer. And unfortunately for hackintoshes, at least for now, you can't retrieve the reason for the panic from any logs, as there are no working nvram-solution available. On a real Mac, the information generated from the panic function in the kernel will, if possible be stored in nvram. For hackintosh, we need to make another more cumbersome route to get the hard facts about the panic. Because this screen seen from the GUI, although much prettier than in other OS's, doesn't say squat about what really happened.

So now what? The only way for a hackintosh, will be to recreate the circumstances that lead to the panic. But before we attempt to do just that, we must ensure in a way that we can see the real panic screen, with the all the numbers and debug data. We have basically two-three options, depending on how we are able to recreate the case. If it only happens during the GUI, you will need to start OS X in verbose mode. To do that you need to pass the infamous -v flag at boot. Or in Chameleon, you can choose the appropriate boot flag from the Chameleon screen. The other option (or rather two options) are if it happen during boot-up or can be recreated from the console (i.e. terminal), if it happen during boot-up you may use the same method as above for GUI. However if you can recreate the case from terminal, you can log into the console mode from the GUI. To do that you will have to do the following first:

• Go to "System Preferences" and choose "Accounts"
• Choose "Login Options"
• If necessary unlock, and choose the option "Display login window as:" to "Name and password"
• Now enter the menu under "" and choose "Log Out xxx... ⇧⌘Q"
• When the login screen shows up, write ">console" in the "Name:" field
• Then login with your username and password in the console screen.
• Now can you try to recreate the panic.

Hopefully (at least for the circumstance) you should be able to see something else than the above screen and it should look something like this:


There are various kinds of panics, so yours will be different (this is a generic model for illustration), but you will see the pattern quickly. To help a developer or an administrator or someone else to debug your panic, this is what is needed and not the above screen which tells us nada, except for the fact that it panicked.

Frequently Asked Questions
Ⓠ What is the most common reason for random kernel panics without any clear pattern?
Ⓐ If it happen completely random, it is often a sign of RAM or HD malfunctioning.

Next... I will go through some common panics and describe what you really are seeing, maybe you can deduce for your self what really went wrong.

Page fault

This is the most common processor caused panic. All kernel trap panics are caused by exceptions from running processor instructions. Page faults are usually when you try to access memory that is invalid. Other common exceptions are divide by zero, general protection faults, invalid opcodes, etc.


Analysis - line by line
panic(cpu X caller 0xXXXXXXXX): Kernel trap at 0xXXXXXXXX, type 14=page fault, registers:
cpu X - is which logical cpu the offending panic happened on.
caller - which function called panic
Kernel trap - The kind of panic
at - Which address is the instruction that caused the panic
type - the type of kernel trap
registers - list of registers.

CR0: 0xXXXXXXXX, CR2: 0xXXXXXXXX, CR3: 0xXXXXXXXX, CR4: 0xXXXXXXXX
EAX: 0xXXXXXXXX, EBX: 0xXXXXXXXX, ECX: 0xXXXXXXXX, EDX: 0xXXXXXXXX
CR2: 0xXXXXXXXX, EBP: 0xXXXXXXXX, ESI: 0xXXXXXXXX, EDI: 0xXXXXXXXX
EFL: 0xXXXXXXXX, EIP: 0xXXXXXXXX, CS: 0xXXXXXXXX, DS: 0xXXXXXXXX
All the CPU registers at the point of panic cause, these are for i386 (32 bit), if we were running in x86_64 (64 bit) it would look like these

CR0: 0xXXXXXXXXXXXXXXXX, CR2: 0xXXXXXXXXXXXXXXXX, CR3: 0xXXXXXXXXXXXXXXXX, CR4: 0xXXXXXXXXXXXXXXXX
RAX: 0xXXXXXXXXXXXXXXXX, RBX: 0xXXXXXXXXXXXXXXXX, RCX: 0xXXXXXXXXXXXXXXXX, RDX: 0xXXXXXXXXXXXXXXXX
RSP: 0xXXXXXXXXXXXXXXXX, RBP: 0xXXXXXXXXXXXXXXXX, RSI: 0xXXXXXXXXXXXXXXXX, RDI: 0xXXXXXXXXXXXXXXXX
R8: 0xXXXXXXXXXXXXXXXX, R9: 0xXXXXXXXXXXXXXXXX, R10: 0xXXXXXXXXXXXXXXXX, R11: 0xXXXXXXXXXXXXXXXX
R12: 0xXXXXXXXXXXXXXXXX, R13: 0xXXXXXXXXXXXXXXXX, R14: 0xXXXXXXXXXXXXXXXX, R15: 0xXXXXXXXXXXXXXXXX
RFL: 0xXXXXXXXXXXXXXXXX, RIP: 0xXXXXXXXXXXXXXXXX, CS: 0xXXXXXXXXXXXXXXXX, SS: 0xXXXXXXXXXXXXXXXX
The CRx are control registers, and controls the state of the CPU. RAX/EAX, RBX/EBX, RCX/ECX, RDX/EDX and the Rxx are the working registers where you use to evaluate and calculate and execute instructions on. If you have a divide by zero exception you will see that one of these are 0. xSP is the stack pointer and xBP base pointer, xSI and xDI are used for string comparing and xFL are general instructions flags. xIP is the instruction pointer and you will see that it will usually be the same as the "Kernel trap at" address, because that is where the panic was caused. Some knowledge of assembly programming is necessary to have understanding of what all registers do.

Backtrace (CPU X), Frame : Return Address (4 potential args on stack)
The backtrace is an attempt to find return addresses from the stack, i.e. the function calls, and an educated guess for what the arguments to the function could be. Some knowledge of the c-calling convention in assembly is required. If the kernel is not able to deduce any functions only the addresses that is potential returns are displayed.

Kernel Extensions in backtrace (with dependencies):
If the return addresses are belonging to an kext the kext-name will be displayed here along with its dependency.

BSD process name corresponding to current thread: kernel_task
Which BSD task, i.e. running task is the current thread that caused the panic. If it happens inside the kernel the task is curiously enough called "kernel_task", but it can also be an application that causes it, and it will be displayed here, although an kernel trap will always be inside the kernel.

Mac OS version:
Kernel version:
System model name:
Should be self-explainable

System uptime in nanoseconds: Uptime
Also should be reasonable easy to understand, the time for start of the kernel to the panic (in nanoseconds = 1/1000000000 second)

Panic call

For some reason has the developer of the kernel or the kernel extension decided that panic should be called. It could be that the system is not in a dangerous state right at the moment it happens, but will quickly be, or if the system continue running it will quickly end up in a hang or another ugly situation. Of course calling the panic instruction is a very dementrious thing to do, so the programmer should have a really good reason to do it. A common example from hackintosh world is if the kernel is not able to find and load the platform expert: "Unable to find driver for this platform "platform expert name""


You will see many of the same things as in the Page fault/Kernel trap panic above, except that there will be a descriptive text where the reason is.

There are other cases, but most of them are similar to the ones above. If you come across one that is markedly different, you can post it here and we can do an analysis. But it must be a Tiger, Leopard or Snow Leopard one and for Intel CPU. PowerPC and panics on earlier versions are different, but do contain somewhat the same data.

More information:

• Apple Technical Note TN2063 - Understanding and Debugging Kernel Panics

That's helpful