Blue Screen of Death for Mac OS X 349
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."
Not like Microsoft invented it... (Score:5, Informative)
It's not like Microsoft invented it, either. I remember these [wikipedia.org] 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.
Likewise (Score:4, Informative)
Re:Not like Microsoft invented it... (Score:5, Informative)
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.
Stupid boring new crash screen... (Score:5, Informative)
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...
Gray screen of death (Score:3, Informative)
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.
Re:Well on the upside (Score:5, Informative)
Review... TN2063 [apple.com], TN2118 [apple.com], Debugging the Kernel [apple.com], etc.
Re:Not like Microsoft invented it... (Score:5, Informative)
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" [quickerwit.com] 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.
Re:Well on the upside (Score:3, Informative)
Actually, it's possible on Windows as well. Not that I particularly *like* Windows by any stretch of the imagination, but XP and 2003, at least, will write a memory dump to the system swap file to be copied into %systemroot%\memory.dmp on the following startup, provided that it's configured to do so. The memory dump can then be loaded into a debugger to do post-mortem debugging. It does have a talent for not being the most useful on some configurations - I've run into issues on systems with >2G of memory, generally with the end of the dump file being truncated, but it certainly does save those details for later analysis.
Re:Hidden? (Score:2, Informative)
Re:Keep it simple (Score:4, Informative)
It does not take appreciably more resources either way, and both code paths are fairly simple and well tested.
Re:Gray screen of death (Score:4, Informative)
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).
Re:Not like Microsoft invented it... (Score:3, Informative)
SATA is aimed for desktop systems. Almost no early SATA systems had NCQ, although more and more newer models have it now. It's been tacked on, not central to the design for decades like in SCSI.
Just take the baddest SATA drive around, the Western Digital Raptor 150. A 10,000 RPM drive with NCQ (Note, the earlier 36 GB and 74 GB Raptor SATA drives did not have NCQ. It's a new tack-on)
1) Look at it's benchmarks vs a bunch of SCSI drives for single user benchmarks. [storagereview.com]
Wow, look. It not only blows away other SATA drives, but kills those expensive SCSI drives. This is why the uninformed grandparent things SCSI is 'ancient' tech.
2) Now look at it's benchmarks vs a bunch of SCSI drives for multi user benchmarks. [storagereview.com]
Notice in the top graph where it slaughters every other SATA drive out there except for it's earlier sibling, the Raptor74. It's obviously pretty much the best SATA has to offer.
Now look at the next graph where it is compared to those 'Ancient' SCSI drives. Those SCSI drives beat the hell out the piss-poor excuse of NCQ that that high end SATA drive has.
That's why SCSI is still king for server work.
I've got a Raptor 150 in my home gaming machine. It's great. But I'd never think about it in my RAIDed servers at work. It just couldn't come close to the job the SCSI drives do.
Re:I've seen two and one was oddly today (Score:3, Informative)
What surprised me was that I had only ever seen the kernal panic only once before after using OS X daily over two years... and that was when I was trying to crash it. (Hint: disabling network adapters and enabling others while connected to an SMB share can cause unpredictable results under 10.3)
While changing the crash message is interesting, it's not something that will make that much of a difference. I'm not going to say that OS X doesn't crash; after all, I managed to crash one by doing something rather safe. It's just not going to be a practical joke that has a quick payoff.
Re:Gray screen of death (Score:4, Informative)
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.
Re:Keep it simple (Score:3, Informative)
From TFA, the crash screen is a single image file, a screenshot. It's probably no harder to load a single screen than a stream of text. And OSX does have an option to display text error messages if you really want to see them.