Blue Screen of Death for Mac OS X
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."
But then MS made the brillant decision to reboot the system right when the BSOD appeared, robbing it of any usefulness. Or perhaps they didn't do it on purpose, but I've seen plenty of displays just go blue for a split second, then blank as the system started rebooting.
Please correct me if I got my facts wrong.
It already has a black screen of death. Favourite for causing it is to plug in certain brands of firewire hard drive (once did it with a USB network card too).
If the OS itself hasn't failed just the GUI you get the spinning wheel of death..
Never heard of any kind of option that "hides the ugly kernel panics behind a nice looking GUI".. possibly a 3rd party app he's installed.
There was actually a number complaints about the BSOD and another about kernel panic screen savers that RedHat removed those from screen savers. If you search the fedora-list archives you should find the original emails complaining about it. ;-)
Whatever happened to the Longhorn / Vista 'Red Screen of Death'?4 15335.aspx
Red is so much scarier.
http://blogs.msdn.com/michkap/archive/2005/05/07/
A system crash with a tasteful little box can be as easily dispised as all the the preceding.
that is precisely true.
My machine at work has some kind of hardware problem that was never quite solved while it was under applecare. it "panics" at least once a day, some days, it'll "panic" 5-10 times. Some things that set it off are scrolling in a terminal window (such as when I'm sync'ing portage on our server) or putting an audio CD in the lower optical drive.
The last time we brought it to tekserve, they claimed that both scsi drives were bad and they replaced them, and we didn't have a panic for a couple months, but by the time they came back (and with a vengence, I might add), there was no more applecare coverage...
I quote "panic" because sometimes I get that nice pretty "please restart your computer" screen, sometimes I get the text dump on the desktop, and sometimes the machine locks up, altogether.
luckily, we're getting one of those nice quad-xeon machines as soon as adobe releases the new creative suite, at which point I'll throw this machine out of a window.
...spike
Ewwwwww, coconut...
Maybe half a dozen? That's since 2000, when I installed the Beta, and then 10.1. Two causes: when I installed Panther, I got a new USB hub at the same time. Half my kernel panics right then. It was a bad hub that delivered less than its rated power. BAM! Later, when I moved up to the G5, I moved my old OS over from the G4. I used Carbon Copy Cloner, but I screwed up something -- I now use SuperDuper! because it's a real Mac app -- and something got really screwy about root and my admin account. Again, another three reboots. Did a fresh erase and install, no problems since then.
That's about 6 years now.
I take it you don't run any servers. SCSI is vastly superior to SATA in a server role. SATA is better for single user work, but if you are tossing many file read/writes at the same time at the drive, SCSI will simply way out preform SATA.
Obviously you are NOT ready for the Mac. Come see the light, friend.
Do you really think that Apple have decided error codes and detailed crash reports are not important?? No, of course they have not. There are two reasons Apple does this.
1) The truth is that the infamous blue page of kernel farts that windows spews out are only to technicians or sysadmins. The home user, and in fact, the power users, can do nothing with it. Nothing, of course, except Google for the stop code and hope Microsoft has a techhelp article on what it means. You can reply to this and say that
makes perfect sense to you... but you'd be lying. I know that the relevent part is 8E but 99% of users NEVER NEED TO SEE THIS and will NEVER USE IT.
Back to Apple. Apple has a little ditty called the "CrashReporter" and it has an OSX front-end to the system's log filed in
2) What do you do with the BSOD info displayed?? A true nooblar would write it all down. That's a waste of time, becuase its also in Windows' system log. Assuming you're going to Google for it, you would presumably reboot the machine, right? So why did we even need to see the error when it happened? The machine is up not, and the logs are visible...??
Bottom line: Apple's goal is to keep things simple, clean and friendly. What would your parents rather see?
Which one?
P.S. - Don't even think about saying "what happens if you cant boot." If that is the case, remove the new hardware. Otherwise you are in DEEP trouble... the code doesnt really matter and you'd actually be better off reading the error from
There are 10 types of people in the world. Those who understand binary and those who do not.
Uhh, am I missing something? Any sensible OS should not allow a program to write to a full disk. Period. It should return from the fwrite (or equivalent) syscall with a failure and the worst that would possibly happen is the program would crash because it did not handle that correctly (well, aside from losing the data that the program was desperately trying to write). If it decides to start randomly overwriting already allocated disk blocks, then that is a very poorly written OS indeed.
I wouldn't trust an option like that to begin with. Something unexplained happened in the kernel - probably memory corruption. In this broken state, are you going to trust the filesystem code to update all those complex data structures correctly? The traditional Unix answer is to write to a dedicated crash partition, which is much simpler. The RedHat answer is to not touch the disk at all - instead, send the data over the network. It's much harder to damage anything while doing that.
For extra craptacularity, do this while installing a system update. Then you get to manually install the update in single user mode before your system will be bootable again. When I say manually, I mean manually extracting files from the pax archive and copying them to the appropriate location because systemupdate thinks that everything is OK despite dozens of system files modified by the update being mysteriously zero bytes in length.
In my defense, the update was taking a long time, the second monitor was a my TV, and my PowerBook is my DVD player.
Power spike conspiracy? Umm yeah. Here's what the XP BSOD looks like. Its real. Sheez, I never thought I would have to defend the BSOD on slashdot.