X

Tutorial: Avoiding and eliminating Kernel panics

Tutorial: Avoiding and eliminating Kernel panics

CNET staff
12 min read

What exactly is a kernel panic?: Basically, this is one of the lowest level crashes that Mac OS X can experience. It's a dead-end hang for the kernel -- the crucial center of Mac OS X that handles various aspects of hardware/software interaction and system calls. When a kernel crash occurs, the system generally cannot recover without a restart of the kernel -- requiring a full restart in Mac OS X.

The hardware/software communication duty is part of the reason so many periphery devices and RAM issues are implicated in kernel panics; since the kernel handles how programs are loaded into memory, and how applications call and respond to external devices (among other duties) a loose RAM module or a FireWire hard drive with bad firmware can throw the kernel for a fatal loop.

The kernel's interaction (direct or indirect) with virtually every application, connected device, processor, software cache, and network service, however make its crash suspects a broad bunch. As with many other Mac OS X troubleshooting techniques, its often easier to throw multiple relatively harmless solutions at the problem of repeated panics in the hopes that one or more will stick.

Potential Causes and Solutions

Bad memory (RAM)

Problematic RAM modules constitute a primary cause of kernel panics that occur in a seemingly random fashion. If you have kernel panics that don't seem to be specific to any device, application or intensive CPU activity, you may have bad RAM.

You can sometimes determine if you have a "bad" RAM module by using the Apple Hardware Diagnostic CD, included with all currently shipping Macintosh models. To use the Apple Hardware Test CD, restart your computer while holding down the C key until the "Loading..." icon appears. On other Macs, a hardware test can be performed by inserting the Mac OS X Install CD and holding down the "D" key while the system is starting up.

Note that the Apple Hardware Test cannot be used when a mouse is directly connected to the USB port on the display or on the iBook. Apple says "Please connect the mouse to a USB keyboard."

If the Apple Hardware Test does not show any errors and you are still having problems, you may want to try removing each RAM module one-by-one and checking for persistence of the kernel panics.

Also, not that different iterations of Mac OS X or updated firmware can prove more temperamental with some RAM modules than the previously installed software/firmware revision. In other words, an OS or firmware update can introduce kernel incompatibilities (and panics) with hardware, including RAM.

Bad NVRAM NVRAM consists of a small amount of memory dedicated to storing important settings for the way Mac OS X interacts with hardware components. For instance, one NVRAM variable tells the system how much primary RAM to recognize.

These settings can sometimes become correct or otherwise problematic, occasionally resulting in a kernel panic. As such, clearing NVRAM can prove a quick fix when the cause of random kernel panics or particularly kernel panics at startup proves elusive. (see "Kernel panics at startup or shutdown" section below).

In order to reset both NVRAM and PRAM hold down the Command, Option, P and R keys at startup until you hear three startup chimes (this resets both PRAM and NVRAM).

Bad devices

FireWire and USB devices are second only to problematic memory in their widespread ability to cause kernel panics. The reasons are varied, but one prominent trait of susceptibility  in FireWire and USB devices is their tendency to ping the system's host controller frequently. If the host controller gets corrupt packets, a kernel panic can result.

FireWire and USB devices are most likely to cause kernel panics right as they are connected, right after the system is turned on, or while the system is waking from sleep.

As such, some kernel panics involving problematic devices can be avoided by simply never allowing your system to sleep. This can be accomplished by sliding the "Put computer to sleep when it is inactive for:" bar to "Never" in the Energy Saver pane of System Preferences.

In other situations, a problematic cache may be to blame (see the "Bad Caches" section below). You may want to try doing a deep clean of system caches with a tool like Cocktail or Tiger Cache Cleaner. Doing so has been known to restore connectivity with, and eliminate problems caused by problematic USB devices and potentially corrupt kernel extension caches. Resetting NVRAM (by holding the Command, option, P and R keys at startup) can also sometimes resolve issues.

The best and most reliable workaround, however, is to disconnect all devices, then re-connect them one by one (over a series of days if necessary) and check for persistence of kernel panics. This can be tricky as some devices only begin to exhibit kernel panics after several minutes or hours of use.

Another grouping of devices that (perhaps surprisingly) can cause frequent kernel panics is the UPS (Uninterrupted Power Supply). The solution in most cases is to avoid activating the UPS while the system is asleep.

SCSI devices can also cause kernel panics. Most notorious is an issue with SCSI hard drives, linked to an array of Adapter kernel extensions.

A common fix involves removing the following files from the /System/Library/Extensions folder:

  • Adaptec 290X-2930.kext
  • Adaptec 29160x.kext
  • Adaptec 39160x.kext
but leaving the file
  • Adaptec 78XXSCSI.kext

Kernel panics caused by SCSI devices can also be specific to a manufacturer's card. Try switching in a different SCSI expansion card (PCI, etc.) and check for persistence of kernel panics.

One common thread among external devices (and internal ones as well) with regard to kernel panics: Up-to-date firmware is key. Iterative updates to Mac OS X can introduce new conflicts with devices, and manufacturers are constantly scrambling to bring hardware drivers and firmware in line.

Another often overlooked workaround is to simply use a different brand of device. For instance, Apple's external USB dial-up modem has been the cause of kernel panics for some Intel-based Macs. Apple's technical support department (at the time) actually recommended using a different external modem.

Another overlooked workaround is to add or remove a "device buffer." By "device buffer," we mean a peripheral like a USB or FireWire hub, an AirPort Base station or any other layer that separates your Mac from a direct connection with the device. In some cases, connecting the device directly to a Mac can resolve the problem. In other cases, only the indirect connection will result in an elimination of kernel panics.

Bad network connections Terminating all network activity -- in some cases necessitating a power-down of the AirPort card or disconnection of an Ethernet cable -- is, in some cases, particularly effective at eliminating kernel panics that occur at startup or when waking from sleep (see "Kernel panics at startup or shutdown" below).

Bad built-in hardware (including hard drives) Repeated kernel panics can be the result of incompatible, damaged or misconfigured built-in hardware. This includes built in AirPort, Bluetooth and other networking hardware, corrupt or damaged hard drives, faulty processors and more. Examine your crash log (as discussed in our tutorial "An introduction to reading Mac OS X crash reports") for clues as to which device is implicated.

Sometimes the fix is as simple as re-seating built-in hardware. Make sure any PCI, PCI Express, AirPort and other expansion-type hardware is firmly and properly seated in its appropriate port.

In other cases, the fix involves attacking the problem at a driver or kernel extension level. Again, examine your crash reports and look for components specifically linked to certain hardware. For instance, the following Mac OS X components are all used by Apple AirPort hardware, and can be implicated (by crash logs) in kernel panics:

  • com.apple.driver.AirPortAtheros5424(100.21)
  • com.apple.iokit.IONetworkingFamily(1.5.0)
  • com.apple.iokit.IOPCIFamily(1.9)
  • com.apple.iokit.IO80211Family(110.19)

After determining device-specific components, you can try re-installing them -- either by performing an "Archive and Install" of Mac OS X, or downloading and manually placing items.

Bad Settings Incorrect or corrupt Mac OS X/application settings (or the container files that store settings) can be the cause of kernel panics.

Usually there are at least some clues to help you determine which settings could be culpable. For instance, if kernel panics occur while the system wakes from sleep, goes to sleep, or puts the hard drive to sleep (during low activity), energy savings may be to blame. Turning off all energy saving options in the Energy Saver pane of System Preferences can resolve issues in these cases.

This can be accomplished by entering the Energy Saver pane of System Preferences, clicking on the "Options" tab, then unchecking all options, including:

  • Wake when the modem detects a ring
  • Wake for Ethernet Network administrator access
  • Restart automatically after a power failure

If you can't find a reasonable clue for which settings to clear or change, you might want to try taking a blanket approach. This usually involves creating a fresh user account, which will eliminate any problematic user-level settings.

Creating a new account is easy enough -- simply open the "Accounts" pane of System Preferences, click the padlock and enter your administrator password, then press the " " (plus) button to create the new user. You'll probably want to check the box for "Allow this user to administer this computer" at first, then uncheck it when you've made the necessary changes (Using a non-administrator account for day-to-day tasks is recommended for security purposes).

If you still can't find the specific cause of your issue but the new user account doesn't experience kernel panics, you will want to delete the old, corrupt user account while retaining the data that you would like to transfer into the new, working account.

Login to your new administrator account using the password you specified, and again go to the "Accounts" pane of System Preferences. This time, select the old account and click the "-" (minus) sign at the bottom. Click the "OK" button (do not click "Delete Immediately).

The old user account will be deleted, and all of the information, documents, and preferences for that user will be stored in a disk image (.dmg) file -- located in the "Deleted Users" folder of the Users directory (/Users/Deleted Users/). Mount this disk image, and begin the somewhat tricky process of transferring your personal preferences and data into the new user directory. For more on this technique, see our tutorial "Common workaround -- create a new user account"

Another blanket elimination technique is to startup in safe mode, accomplished by holding the the option key at startup. Starting in safe mode will not only temporarily disable various system extensions, add-ons and settings that could be causing kernel panics, but it will also clear certain caches and settings that could be causing the problem.

Bad Caches System and user-level caches play an integral role in routine Mac OS X operation, and partially for that reason are so often implicated in kernel panics. Clearing caches when you're experiencing repeated kernel panics is a good initial measure before attempting to finger a distinct cause.

As mentioned above, caches are most easily cleaned by using a tool like Cocktail or Tiger Cache Cleaner. There's also a manual process -- delete the following most commonly problem-causing caches through the Finder or Terminal:

  • com.apple.kernelcaches (a folder in /System/Library/Caches)
  • Extensions.kextcache (a file in /System/Library)
  • Extensions.mkext (a file in /System/Library/)
  • com.apple.ATS (a folder in /Library/Caches/)
  • Files that start with com.apple.LaunchServices (in /Library/Caches)

Bad software components This is a difficult class of culprits to troubleshoot because of its inherent vagaries (think a dizzying array of system processes versus a limited number of external USB devices). There are, however, some key areas to start your search for a panic inducer.

Third-party software

Virus software The category of virus software has emerged as one of the more problematic with regard to kernel panics. In particular, use of "automatic scanning" or "background scanning" functions -- which scan every new file created or saved -- has proven a consistent cause of various ills, including kernel panics.

Your best bet -- if you are experiencing repeated kernel panics related to virus software -- is to disable automatic scanning and check for persistence of the issue.

Heavy hitters Other often-implicated programs are those that make frequent use of low-level system calls to hardware or extremely RAM/processor heavy apps. Virtual PC, for instance, has been known to cause kernel panics soluble through deletion of emulated devices.

Extended or bandwidth-intensive disk transfers initiated by applications -- such as long file copies or disk maintenance -- can also be the cause of kernel panics. Try to make a note of whether or not there is any correlation between heavy disk activity and your panics, then seek out firmware, connection or directory damage issues.

Mac OS X components Mac OS X components are subject to a variety of complications, including data corruption, incompatibility with hardware, permissions problems and more. Tracking down the component responsible for kernel panics can be tricky, but fortunately there are some "shotgun" techniques that can help resolve, if not identify the cause of, repeated panics. A good blanket method of eliminating problematic Mac OS X components that could be causing kernel panics involves performing an "Archive and Install" process. This procedure will retain important user-specific data while replacing (fresh from the Install media) key components of Mac OS X that could be subject to corruption and other issues.  
Kernel extensions Look inside your/System/Library/Extensions folder. Every file in this location is a piece of software that adds on to the functionality of the Mac OS X kernel, can modify its behavior, and potentially be the source of kernel panics. At a count of 250-350 kernel extensions (they reside in other locations as well) on an average system, there's a lot of room for error. Fortunately, most kernel extensions are clearly labeled, and you can look through the /System/Library/Extensions folder for items that match the name of any device or hardware component that is accessed whenever a kernel panic ensues. Other logical connections can be made.
  • Dial-up modem panics: InternalModemSupport.kext
  • Various USB (Printer, drive, camera, etc.) related panics: IOUSB.kext
  • Trackpad issues on some portables: AppleADBMouse.kext
  • AirPort panics: AppleAirPort.kext

Once you've found the culprit, your best bet is to replace it by copying from another healthy Mac OS X system, extracting it with Pacifist, or by simply re-installing the latest Mac OS X combo updater or performing an Archive and Install.

Post-update panics Kernel panics can sometimes start occurring after an incremental Mac OS X update, Security Update or other major system modification. If this is the case, reversion to a previous system state can often resolve the issue.

Kernel panics at startup or shutdown

Pre-shutdown routines can prevent issues at next startup As touched upon above in the "Bad Network Connections" section, terminating certain services -- including Network services, Bluetooth connections, sharing services, and more -- at the time of shutdown or before putting a system to sleep can prevent kernel panics that occur at the next system startup or wake from sleep.

Simply try disconnecting from such services (turn of Bluetooth, AirPort, disconnect Ethernet cables, etc.) before shutting down or putting the system to sleep, then check for persistence of issue at the next startup or wake. If the problem does not persist, you can at least identify from which service the kernel panics are stemming, then approach the problem at a driver or settings level.

Kernel panics after the lid is closed Mac OS X portables sometimes exhibit a troubling issue where the system kernel panics after the sleep command is invoked by closing the lid of a portable. This can result in an issue where the system fails to go to sleep, and instead stays on and active while the lid is closed. This can be particularly worrisome if you place your Mac portable in a bag after an incident, because the system will generally become extremely hot and fans will ramp to full speed.

Startup Items Look in the /Library/StartupItems folder if you are having kernel panics at startup. Remove any third-party items and check for persistence.

Startup Items can also be the cause of kernel panics that result from conflicts with other software that is launched at any time other than startup. As such, don't count this location out as a harbor for problem-causing files.

External devices If it seems like external devices have been a thread throughout this article, look no further than the second paragraph for explanation. A common cause bears constant mention, and startup is no exception. Disconnect all external devices if you are having a kernel panic at startup or shutdown, and leave them disconnected until the system is fully booted. Then connect them one-by-one and see if the issue persists, either in general usage or at startup and follow the steps listed in the "External Devices" section above.

Like what you've found in this tutorial? Get more troubleshooting guidance (updated daily) by subscribing to MacFixIt Pro.

Resources

  • Cocktail
  • Tiger Cache Cleaner
  • cause of kernel panics
  • "An introduction to reading Mac OS X crash reports"
  • "Archive and Install"
  • "Common workaround -- create a new user account"
  • cause kernel panics
  • with Pacifist
  • reversion to a previous sy...
  • subscribing to MacFixIt Pr...
  • More from Tutorials