To view parent comment, click here.
To read all comments associated with this story, please click here.
It doesn't help the end user - but if the end user has to bring in a support tech, they can usually decipher the error code (even if "deciphering" means "search for it in Google", which is usually the case with Windows BSODs).
IMO, the ideal would be a terse "an error has occurred" message - with an option to show more details.
That said, both of my biases are showing. As a result of doing a lot of technical support, I believe that computer software/hardware should be evaluated based on how easy it is to diagnose and fix problems when they occur (and not just how well it works in normal situations).
And as a BeOS devotee, the "ideal" I described is essentially how things work(ed) with that OS: you get a "Welcome to Kernel Debugging Land" message, with a prompt that lets you run a stack crawl, etc, if you need more details.
"Guru Meditation"
None of what follows is meant to suggest that the average user is expected to know, or even want to know all of this - but some users do...
I can work with Windows BSODs and they can be helpful, but they are far from elegant.
However, for the user who bothers to learn there is a related tool that can be quite helpful in determining the reason for the kernel panic.
If the computer has Windows and reboots instantly than it is unlikely that anything was written anywhere. But if it BSODs you will most likely have a MiniDump file. (Haven't you ever wondered why it sometimes takes so long just to display a blue screen with white text on it?)
The OS writes something to the Event Log, which does help, but even better are the MiniDump files. But it should be understood that when you first try to view a MiniDump file the process feels quite sadistic.
I mean, here you have a file that might just tell you all the intimate details about the crash that just happened, only there is nothing on your computer that can read it. I wish Microsoft didn't make accessing them so difficult.
You have to install the Debugging Tool, and the Debug files for your OS in order to properly access the Mini Dumps. You also need to know where they are written - this will be in the Windows folder, but (I am not positive) I think the location may vary from OS to OS.
Anyway, the BeOS method sounds like the better one to me, of the ones described. It gives a simple message, allows you to dig in deeper, if you want, and the OS already includes the necessary tools.
Whatever OS I use, I just continue to hope for fewer kernel panics, and better tools for problem solving when the inevitable occurs.
I appreciate it when the OS uses its last dying breath to give me clues as to who the killer is, and I hate digging deeper and deeper only to find more and more cryptic messages that have fewer returns when searching the related OS forums.
Edited 2008-08-14 22:14 UTC
It helps me, and I'm sure lot's of other people that look after Windows systems. Generally speaking, the first point of call for a bugcheck code is support.microsoft.com, then Google.
And the bugcheck code get's written to the event log, even if the system reboots (unless the system really locks, then there is no evidence).




Member since:
2005-07-06
ignorance is a bliss, right? ...
And a laundry list of 'codes' helps the end user - how? Microsoft have already demonstrated that they refuse to make available the list of error codes for BSOD's when they occur; heck, Microsoft has gone so far as to have automatic reboots instead of actually showing a BSOD.
The laundry list of Linux codes - that helps the user how? again, there is no standardised error codes, nor is there a single place to look up those error codes.
Screaming about the wonders of actually seeing a dump from a kernel panic may get your loins excited, but for the average end user - it is all Greek to them.