Why did they have to make the BSOD so ugly? (poll)

[clicknext]

Couldn't they think of something better looking at least for Win2000/XP? Or does the ugliness just contribute to the message that you are really screwed?

 

[n0cmonkey]

When did Christina turn ugly?

I think the BSOD is just basic. At that point you don't want something flashy, you want something that works. BSOD conveys information well enough.

 

[dclive]

Originally posted by: n0cmonkey
When did Christina turn ugly?

I think the BSOD is just basic. At that point you don't want something flashy, you want something that works. BSOD conveys information well enough.

Exactly. What's the problem with the BSOD? It tells you exactly what's going on in the machine in question.

 

[drag]

Well. For one thing Macs show their intense superiority in yet another way.

Before in Windows, it would crash and dump you to the command prompt. The Macs would just get snow all over the screen. It's suprising and pleasent. It's helpfull because it would immediately indicate to the user that they are over their heads and shouldn't bother trying to fix it. While the DOS guys would try to fix it possibly thru the command line and possibly make it worse.

Then while MS was perfecting the BSOD the Apple geniuses would have the macs get a little cartoon bomb on the screen. See that's funny and classy way for a computer to take sh!t. Makes people smile and imagine little deamons running around tossing bombs at the computer's harddrive.

Then later on while we were getting familar with the stark reality of the BSOD's continued presence in w2k and WinXP, Apple was perfecting the "going japanese" multi language, and very helpfull isntructions that basicly read "Reboot this computer now" but with 3 times as many words.

Now while Apple forges onto the future with pleasent and interesting looking images such as these, MS stolidly refuses to move it's BSOD computer technology into the 21st century.

Mac's continued superiority in crash screen technology is just indicative of it's continued dominance in cutting edge software and hardware personal computer technology.

 

[n0cmonkey]

Originally posted by: drag
Well. For one thing Macs show their intense superiority in yet another way.

Before in Windows, it would crash and dump you to the command prompt. The Macs would just get snow all over the screen. It's suprising and pleasent. It's helpfull because it would immediately indicate to the user that they are over their heads and shouldn't bother trying to fix it. While the DOS guys would try to fix it possibly thru the command line and possibly make it worse.

Then while MS was perfecting the BSOD the Apple geniuses would have the macs get a little cartoon bomb on the screen. See that's funny and classy way for a computer to take sh!t. Makes people smile and imagine little deamons running around tossing bombs at the computer's harddrive.

Then later on while we were getting familar with the stark reality of the BSOD's continued presence in w2k and WinXP, Apple was perfecting the "going japanese" multi language, and very helpfull isntructions that basicly read "Reboot this computer now" but with 3 times as many words.

Now while Apple forges onto the future with pleasent and interesting looking images such as these, MS stolidly refuses to move it's BSOD computer technology into the 21st century.

Mac's continued superiority in crash screen technology is just indicative of it's continued dominance in cutting edge software and hardware personal computer technology.

Microsoft should go with comic book villian error messages. Maybe a purple screen of death with the Joker, or the Riddler giving his famous "riddle me this" line. Or for really sexy errors some kind of Poison Ivy/Catwoman (and not that injustice of a movie Halle Berry is putting out) team up... 😀

 

[dclive]

Originally posted by: drag
Well. For one thing Macs show their intense superiority in yet another way.

Before in Windows, it would crash and dump you to the command prompt. The Macs would just get snow all over the screen. It's suprising and pleasent. It's helpfull because it would immediately indicate to the user that they are over their heads and shouldn't bother trying to fix it. While the DOS guys would try to fix it possibly thru the command line and possibly make it worse.

That's got to be the faultiest logic I've seen in a while.

Then while MS was perfecting the BSOD the Apple geniuses would have the macs get a little cartoon bomb on the screen. See that's funny and classy way for a computer to take sh!t. Makes people smile and imagine little deamons running around tossing bombs at the computer's harddrive.

Then later on while we were getting familar with the stark reality of the BSOD's continued presence in w2k and WinXP, Apple was perfecting the "going japanese" multi language, and very helpfull isntructions that basicly read "Reboot this computer now" but with 3 times as many words.

Now while Apple forges onto the future with pleasent and interesting looking images such as these, MS stolidly refuses to move it's BSOD computer technology into the 21st century.

Mac's continued superiority in crash screen technology is just indicative of it's continued dominance in cutting edge software and hardware personal computer technology.

Ah - humor. 🙂

 

[Barnaby W. Füi]

Originally posted by: dclive
That's got to be the faultiest logic I've seen in a while.

....

Ah - humor. 🙂

See sig 😀

 

[Nothinman]

Couldn't they think of something better looking at least for Win2000/XP? Or does the ugliness just contribute to the message that you are really screwed?

It's a kernel debug screen, why do you care what it looks like? It's done in really low level code so it has to be simple otherwise you risk corrupting the output, i.e. if the video driver is what crashed and you do something stupid like try to make the BSOD screen pretty by using 32-bit color and animating it chances are the box will just hang instead of giving usefull output.

 

[Psych]

A big pain with older BSOD was that you can't scroll through them! I haven't experienced a true BSOD in XP yet, though, so I don't know if MS has made any leaps and bounds in the area of error screen aesthetics and practicality.

 

[dclive]

I don't see the point in your complaint, Psych - that's what the memory.dmp is for! Since you have a memory.dmp, you have a complete record of what was going on inside the machine, and you can easily debug it and fix the problem.

 

[Nothinman]

A big pain with older BSOD was that you can't scroll through them! I haven't experienced a true BSOD in XP yet, though, so I don't know if MS has made any leaps and bounds in the area of error screen aesthetics and practicality.

There's nothing to scroll, the message fits on one screen. And it's technically called a STOP error because the kernel has STOPed, if you could scroll the kernel would need to be running.

 

[boran]

the whole point is that when your machine bsods it just hangs and the things you can do are very limited, and who cares about looks when you're screwed ? wont make the event any nicer.

 

[gsellis]

Nothinman gets :beer:

 

[Sianath]

The processor is still running when you get a bugcheck (how do you think we are writing the data!). The closest you can get to actually stopping is a double-fault, which we still trap (Stop 0x7f). The original VPC (prior to us grabbing it) didn't know how to trap a double-fault though, which is why it would occasionally just reset your computer for no apparent reason.

The reason we bugcheck is because something has happened that is not allowed, and in order to prevent memory/data corruption, we trap the current process and transfer control to an exception handler based on the reason for the exception.

We try our hardest to make sure you can get a dump of what is going on so you can FIX the problem. This means displaying data in the most simple manner possible, using code that will function even if we need to revert to real-mode due to issues with drivers.

Sure, we could spend a lot of effort trying to say "F off!" in a neat pretty way when an error occurs, but we felt our time was better spent providing data and diagnostic information so that you can prevent the issue from coming back.

🙂

 

[Sunner]

I agree, it show a pr0n movie instead, you should even be able to configure what kind, for example vanilla, lesbian, gangbang, etc.
Imagine how much happier users would be when their computers crashed if instead of a dull blue screen, they saw some nice porno.

 

[Nothinman]

The reason we bugcheck is because something has happened that is not allowed, and in order to prevent memory/data corruption, we trap the current process and transfer control to an exception handler based on the reason for the exception.

You try to prevent data corruption by writting a dump file to the hard disk? That makes no sense what so ever.

 

[gsellis]

Originally posted by: Nothinman

The reason we bugcheck is because something has happened that is not allowed, and in order to prevent memory/data corruption, we trap the current process and transfer control to an exception handler based on the reason for the exception.

You try to prevent data corruption by writting a dump file to the hard disk? That makes no sense what so ever.

As quoted. If you have a critical error, there are many errors that now invoking a write to the file system might not be the best thing to do. You might be pointing to where you think you are. There were 3 kinds of stops in NT, 1) error, 2) error while processing error (stop 8?), 3) freeze as error processing error processing error so I am completely lost.

As a footnote, MS is moving video back to user out of kernal. Too many video driver issues causing BSOD. User error can be recovered where kernal is death.

Historical footnote - BSOD originally stood for Black Screen of Death. MS internal folks credit Charlie Rogers with the coinage of the term. The original problem that caused this was a Novell/MS network driver problem in DOS/Windows 3.0. Windows would disappear and there would be a black screen with a blinking cursor in the upper-left hand of the screen.

 

[Nothinman]

IMO any in-kernel error that causes a STOP should just stop the system cold, like a panic in unix, and touch nothing else because you have no idea what has been changed or corrupted. Commercial unixes that do a memory dump put the data on a swap partition which is as close to safe as you can get since there's no filesystem there to trash, but Windows drops it right in the middle of the Windows directory which just seems down right dumb.

 

[Sianath]

"You try to prevent data corruption by writting a dump file to the hard disk? That makes no sense what so ever."

In order to understand the process, you need to understand how data is stored on the machine, and what is happening internally that can cause a bugcheck to occur.

You are confusing data corruption (corrupting data in RAM) with physical data corruption (something being physically written to disk). We bugcheck to PREVENT anything in RAM that has been corrupted from being utilized by another process (and thus, possibily affecting on-disk data).

As a side note, we are never overwriting a user's data when we write a dump file. When you bugcheck, we write the contents of RAM to your page file, reboot the system (or not, based on the auto-reboot option you can set), and after reboot, we write your dump file and recreate your page file.



"As quoted. If you have a critical error, there are many errors that now invoking a write to the file system might not be the best thing to do. You might be pointing to where you think you are. There were 3 kinds of stops in NT, 1) error, 2) error while processing error (stop 8?), 3) freeze as error processing error processing error so I am completely lost."

As stated above, we write to the page file. We don't create a new file, we don't move any files, and we don't resize the page file if it's not big enough.

There were MANY more than 3 types of stop code you could experience. There are three general TYPES of code as defined by the x86 architecture (fault, trap, abort). Your number 2 is close... what you are referring to is a double-fault (Stop 0x7f, first parameter is 8). If not handled properly, a double-fault can triple-fault, causing the CPU to reset (x86 specification for how the processor handles a triple-fault). This was a problem with the Connectix version of Virtual PC before we took it.

Feel free to ask any questions you have on the subject... I would much rather be able to answer questions and clear up misconceptions than watch half-truths and guesses get tossed about as gospel.

 

[Nothinman]

You are confusing data corruption (corrupting data in RAM) with physical data corruption (something being physically written to disk). We bugcheck to PREVENT anything in RAM that has been corrupted from being utilized by another process (and thus, possibily affecting on-disk data).

But if it's in kernel memory by a bug in a driver, how can you be sure it hasn't scribbled on memory in other places and you only noticed one of them?

As a side note, we are never overwriting a user's data when we write a dump file. When you bugcheck, we write the contents of RAM to your page file, reboot the system (or not, based on the auto-reboot option you can set), and after reboot, we write your dump file and recreate your page file.

And what if it's the storage controller that caused the problem that caused the STOP?

 

[gsellis]

Sianath - 7f came into play in W2K IIRC. In NT 4, I am pretty sure a Stop 8 was issued when while processing a kernal fault, another was found (double-fault). If you were processing a kernal page fault, which was fairly common with drivers around SP1/2 days, you could then have another fault occur. The triple was always fun with the system locking. That also changed with W2K.

And as pointed out, there are circumstances that I always wonder if the write to the pagefile is not aborted. The references are protected in a VM arch, but if the fault happens in the IO system...

 

[Sianath]

Stop codes haven't changed from NT to 2000. Just did a quick search internally for old NT double-fault cases, and each one was a Stop 0x7f (8) just to do a quick sanity check.

Page Faults are very common. The entire OS (when in protected/paging mode) is built around getting them, so those are no big deal; we expect them. What you may have been talking about is an access violation (Stop 0xA), which was very common with drivers in NT days, but very rarely happens anymore (now any Stop 0xA is almost never a true Stop 0xA, it is an attempt to access invalid memory vs high IRQL)

A double-fault almost always occurs due to ESP being corrupted. The first thing we do in the exception handler is push a trap frame, and if ESP is corrupted, that will cause another fault. We handle that 2nd fault (preventing a triple fault) in a different manner from other exceptions.

The triple-fault hard reset of the machine did not change from NT to 2000. That is not something the OS handles... the processor itself handles a triple-fault (assuming that if you didn't get the double-fault correct, you won't handle the third fault correctly) by pulling the reset pin on the CPU. It's part of the x86 architecture to do this and is out of the OS's hands (so to speak) because the processor doesn't even query the IDT in the case of a triple-fault.

The only time the write to pagefile would be aborted (or not occur) is if something happens that causes us to lose connection to the disk itself. This is common in situations where you are booting from SAN or have a hard-disk failure (obviously). We have code in the kernel to handle a switch from protected mode back to real mode so we can use BIOS calls to write to disk if necessary, so it's fairly rare for us to not get a dump file.

 

[Spleeze]

Not to hijak your thread, but how many times have you guys actually seen a BSOD on XP?

I've seen it 0 times total, honestly.

I've also seen that error message for OSX 0 times, even though the machine seized up like a corpse on me countless times. 🙂

Explorer can get pretty screwy, but i can kill that and restart it, taking off where i left.

 

[dclive]

Originally posted by: Sianath
We have code in the kernel to handle a switch from protected mode back to real mode so we can use BIOS calls to write to disk if necessary, so it's fairly rare for us to not get a dump file.

It happens all too often, unfortunately.

 

[clicknext]

Originally posted by: Spleeze
Not to hijak your thread, but how many times have you guys actually seen a BSOD on XP?

I've seen it 0 times total, honestly.

I've also seen that error message for OSX 0 times, even though the machine seized up like a corpse on me countless times. 🙂

Explorer can get pretty screwy, but i can kill that and restart it, taking off where i left.

I see the BSOD all the time when I overclock too much. Totally my fault, but I'm just saying it's there. 🙂 Also I think I've seen BSOD on an XP computer at my school while it was rendering 3DsMax.