Every computer system has the capability of crashing. Some self-recover better than others, and some manifest it more elegantly than others. Make no mistake, regardless of what kind of computer you are using, your computer can crash.
I am not particularly loyal to one hardware set or to one operating system. I use them all and I enjoy them all. Having said that, Apple products will tend to be least likely to crash in general. That is because Apple products have ONE standard set of hardware, and installing a Macintosh operating system on non-Apple hardware violates the End User License Agreement (EULA). This one thing, this one restrictive thing, ensures that Macintosh operating systems are running ONLY on hardware that has been tested and vetted. The user experience is completely predictable. Since a very large number of operating system crashes are caused by hardware device drivers, Apple has narrowed down the number of drivers it needs to support and keep track of by controlling the hardware that the operating system needs to talk to.
When a Mac crashes, you will either get a completely unresponsive system for several minutes, requiring a “hard boot” (press and hold the power button until the machine shuts down—shutdown method of last resort), or you will get a gray screen with a message something like, “Your computer needs to restart.” Since device drivers aren’t going to be the problem on a Mac, generally speaking, you may seeing a problem in the hardware itself, or a condition known as “kernel panic.” (By the way, if you have any familiarity with Linux, you might have seen a kernel panic there too, because OS X is based on a Unix version, and Linux is derived from Unix.)
With Linux systems I’ve seen the unresponsive system, and I’ve also seen the kernel panic screen, white text on a black screen. Linux systems are getting much more inclusive with their device drivers, which is a good thing, because one thing that Linux and Microsoft share is the ability to load onto any hardware—even Apple hardware. Some Linux distributions are being supported by corporate effort, but still a huge number of drivers are having to be written by volunteer programmers, so not every version of every distribution of Linux will have every driver for every device for every manufacturer of hardware—just impossible! But with a growing community of supporters, driver and hardware supporting software has improved dramatically in just a decade.
In Windows systems, we call this condition the Blue Screen Of Death, or BSOD, because of, well, a blue screen.
I purposely used a non-English screenshot because the only thing I want you paying attention to are the things I show you.
The arrow marked 1 is pointing to a cryptic message. Okay, it’s true, the whole message, even in English, is cryptic. But to most techs, most of it means something. That spot, with a message in all caps separated by underscores is often all we need to unlock the mystery. But not always; so we move on to spot 2. Each of those groupings can indicate a range of issues that can cause the problem. But not always; so we move on to spot 3. In this case, there’s nothing there. But often in the case of a bad hardware drive, you’ll see in that spot a filename. That’s a good indicator that the filename itself is what caused the problem. If you search for that filename, you can find out what driver it belongs to. Don’t even bother trying to replace or fix that one file—just go grab a fresh copy of whatever driver your research says it belongs to and reinstall it.
If you want to go exploring, you can look in the Event Viewer and see if Windows made a note of whatever it was that caused the Blue Screen. If you were actually using the computer when it happened, you’ll have an approximate time, and since Windows stores those event items chronologically, it should be easy to find. Here’s how to go look at the stuff:
Click on the Start “orb,” and then go over and Right-Click on Computer, and select Manage. In the window that opens, click on the triangle next to Event Viewer, then select Windows Logs. Cruise through the System logs and the Application logs for that time frame. Once again you will be looking at cryptic information. Ever met a programmer? Well these events are written by programmers for programmers. It never occurs to them that “real people” are going to try to use these things. But the events usually have a code that you can use to hunt down the cause of the event.
It can take anywhere between a LITTLE detective work and a LOT of detective work to identify the cause of a Blue Screen. Oh, and the best part? Sometimes a reboot is all you need.