Slashdot Mirror

← Back to Stories (view on slashdot.org)

Blue Screen of Death for Mac OS X

Posted by ryuzaki0 on from the creative-wastes-of-time dept.

An anonymous reader writes "Possibly nothing in the OS world has as much of a bad rap as the infamous BSOD (blue screen of death) in Microsoft Windows. On the other hand Apple hides the ugly kernel panics behind a nice looking GUI which only tells you its time to restart your dead system. Interestingly Mac OS X kernel has a secret API which lets you decide what your kernel panics are going to look like! In this Mac OS X Internals article Amit Singh explains how to use this API. Apparently you can upload custom panic images into the kernel and there's even a way to test these images by causing a fake panic. The article also shows the ultimate joke is to upload an actual BSOD image for authentic Windows looking panics right inside of OS X."

10 of 349 comments (clear)

  1. Not like Microsoft invented it... by ackthpt · · Score: 5, Informative

    It's not like Microsoft invented it, either. I remember these quite unfondly. Before that I had a frozen screen on a C64. And before that I had stopped lights on the PDP-11 display. And before that we had random characters all over the screen of Ohio Scientific (OSI) computers.

    But Microsoft is widely credited with perfecting the BSoD and giving it fame.

    A system crash with a tasteful little box can be as easily dispised as all the the preceding. I suppose, like everything Apple is doing these days, they've given it a certain panache and now everybody will want one.

    --

    A feeling of having made the same mistake before: Deja Foobar
    1. Re:Not like Microsoft invented it... by DingerX · · Score: 4, Informative

      Guru meditations were awesome, and I fondly remember that flashing red border.

      But Amiga wasn't first. The Mac "Bomb" preceded it, and was notoriously useless for troubleshooting.

      Still, most Windows XP users haven't seen a BSOD ever. Go ahead and ask them. See, Windows XP solved that. But mysteriously, their power supply is unreliable, and "trips" on the slightest whim.

      You gotta love that. "BSOD is bad for marketing, and most people don't know what to do with the information anyway. Let's just reset the computer and pretend it's a power spike."

      I'd advise people to change their default settings, but one time I had "write memory contents to log file on BSOD" enabled when I was moving data about, and hand less free memory on my HD than in RAM.

      Don't ever, ever do that.

    2. Re:Not like Microsoft invented it... by Anonymous Coward · · Score: 5, Informative
      It's not like Microsoft invented it, either.

      Microsoft had a single DEBUG line in the registry for Windows 95 -- it allowed the application of your choice to intercept the crash.

      The first commercially successful program to implement it was "Power Utilities 95 with Crashproof" that handled/exposed many hardware conflict sins without just covering them up.

      About 50K copies later and good shelf space at Frys/COMPUSA/BestBuy , Symantec took notice and put out their $29 Crashproofing program that didn't perform dozens of system checks or even unmask the cause of the crash.

      If version 1.0 of that Norton floppy disk consisted of anything more than copying a 1 line registry change and a pointer to a bitmap, then it never showed in practice.

  2. Likewise by Umbral+Blot · · Score: 3, Informative

    Likewise in windows you can change the background color and text color of the BSOD (or at least you could uder 98, I haven't had the desire to play around with it under 2000 / XP since they crash much less frequently).

    --

    Philosophy.
  3. Stupid boring new crash screen... by Moofie · · Score: 5, Informative

    That's not NEARLY as cool as the car crash sound Macs used to make when they really, really, REALLY blew up fierce. Get a good pair of speakers, and that sound would scare the tar out of everybody in the area!

    I think it only happened to me once, on a junky old LCIII, while I was just working. There was a key combo to induce it on boot, though, and I got a lot of mileage out of that...

    --
    Why yes, I AM a rocket scientist!
  4. Gray screen of death by azav · · Score: 3, Informative

    I have gotten the gray screen of death twice on my Quad.

    When capturing QuickTime video, QuickTime writes one copy of the file and then makes another. If you are capturing to a mastering codec (ie animation) minutes can become gigabytes. It is easy to fill up the internal HD in this case.

    What can easily happen in this case is the file writing routines will start writing over allocated blocks. System files, even track zero. If it writes over track zero, your internal hard drive will be destroyed.

    How do I know this? It happened to me twice.

    The second time, I was left with a 17 GB file on my hard drive that can not be deleted by any means other than reformatting the disk. The first time it happened, the HD was borked so bad that plugging it into another Mac caused that mac to kernel panic. Apple replaced the drive but I lost everything minus my backups.

    As I was told by an Apple tech, when a hd starts up the dirve itself checks the validity of track zero. If it is invalid, you have a hardware fault and this generates a kernel panic.

    This was all validated by Apple techs.

    You have been warned. Hope this helps someone.

    --
    - Zav - Imagine a Beowulf cluster of insensitive clods...
    1. Re:Gray screen of death by slamb · · Score: 3, Informative

      This has been a serious flaw in Unixes since I knew about it. The OS will let your HD fill up and overwrite itself. Many *nix flag wavers often defend this behaviour. Why they do is beyond me.


      You're completely wrong. When the free space reaches 100%, write() will return ENOSPC (no space). The superuser will still be able to use the system, because traditionally, there's a 5% reserve which only uid=0 can use. (The "df" goes up to 105%.) The correct semantics are well-defined. If you've seen anything else, it's a bug in whatever system you were using, which no one could seriously defend.

      Now, if you're talking about user applications breaking when encountering this condition...yeah, there are certainly some out there that break. There are buggy applications written for every platform. It's just laziness - Unix gives them well-defined semantics they can use to handle it correctly and an easy test environment (quotas).
    2. Re:Gray screen of death by blob.DK · · Score: 4, Informative

      Excuse me, Sir, but that is a misunderstanding on your part. Mac OS X does not overwrite track zero just because the disk is full.

      What you have experienced is the phenomenom of Mac OS X getting caught up in: "ups, the disk is full - so now I can't save any (system) preferences." Any files written during this will end up as zero-byte files.

      There is no magic "QuickTime will overwrite vital systemfiles, to which only root has access"-routines.

  5. Re:Well on the upside by shawnce · · Score: 4, Informative

    Kernel panic information gets logged on reboot to a file and you can capture a kernel core dump if you want.

    Review... TN2063, TN2118, Debugging the Kernel, etc.

  6. Re:Keep it simple by blaster · · Score: 4, Informative

    The graphical version takes slightly fewer resources. You have to run a single buffer through an RLE decompression routine directly out into a linear mapped framebuffer. To display text you actually have to use all of the console code. Remember, there is no hardware console, so you have to actually do all the text element positioning in software, and the graphics card is in exactly the same mode either way.

    It does not take appreciably more resources either way, and both code paths are fairly simple and well tested.