Microsoft whiz dishes the dirt on the Blue Screen Of Death's colorful past Veteran Microsoft engineer Raymond Chen has taken to his Old New Thing blog to clear up an apparent mystery regarding the origins of the infamous Windows Blue Screen of Death (BSOD). But there is no mystery. Steve Ballmer wrote the text for the Windows 3.1x BSOD, although Chen whimsically called it a "blue screen of …
About 20 years ago someone sent me a Microsoft themed haiku that was apparently someone's submission to a competition. I just googled quickly & found it in this short list of them, most of which are beautiful, & should probably be used as MS error messages. They'd be just as informative but much less rage inducing :
http://allowe.com/laughs/book/Microsoft%20Haiku.htm
But it can't, that's the entire point. The OS has found itself in a situation where we're off the edge of the map. Something has happened that's totally out of bounds and we're now in a situation where doing anything will potentially lead to totally undefined behavior. We can't offer the opportunity to do anything because doing anything could cause we-know-not-what to happen.
A BSOD Isn't just a crash. It's the crash. It's an admission that the OS has totally lost control of the situation and all it can safely do is halt and call for help from a human.
"Put simply, because John's dev machine was a MIPS RISC box, and the firmware on that machine was white on blue.
"And in fact, his favorite editor at the time was SlickEdit, and the default text colors for SlickEdit were also white on blue.
And it's a nice bright colour to make the user feel happier.
The lovefest as you describe it isn't so much for how the OS behaved behind the scenes, but more for how the OS interacted with the humans trying to use it. Because for a desktop OS that isn't being pressed into service to run an ad-hoc server or other thing that requires high levels of uptime, users will generally be more forgiving of an occasional crash than they will be for the constant struggle they have dealing with what, to them, is perceived as an utterly godawful UI design. It's the same principle with any other aspect of the human-machine interface design - what one person finds pleasant to use, another will find a pain, and another will consider to be utterly repulsive. Keyboards, mice, monitors, everything that influences how we interact with the system is key to our being able to make the most of it, and the UI presented to us by the OS is no exception. Get that right (as far as the individual is concerned) and the OS overall is going to feel right. Get it wrong, and it doesn't matter how good the other parts of the OS might be.
I'm firmly in the camp that believes Windows UI design peaked with 7 and has been on a rapid descent into misery ever since, and I've expended countless words to that effect in comments over the years here. Yet I've *also* been very open as to how I appreciate the kernel-level improvements that've come with later versions, so it's not always a clear cut case that anyone who professes a preference for earlier versions is ignoring/overlooking the benefits later versions bring, it can be more subtle than that. And with that, I've also been clear that if MS would simply offer us a version of 10 or 11 with an officially supported classic theme, so that we don't have to rely on third-party tools being able to continue operating OK with each successive OS update, and which, on corporate machines, may be out of the question in the first place, then I'd be a VERY happy bunny.
Because yes, I DO want the behind the scenes improvements that these later iterations of the OS have brought to us, but that doesn't mean I'm ever going to accept the UI designs that come with them, and no amount of people trying to explain how much better they are is going to convince me. I've spent enough decades sat in front of systems to know what *I* want out of a UI, and no matter how much time and effort I put into trying to learn to like modern UIs, I always always ALWAYS find myself wanting to go back to that 90s-00s era which for me, and many others, was the pinnacle of UI design.
Wish I could upvote this more than once!
I was finally dragged kicking and screaming onto Windows 10 earlier this year, only made tolerable by the use of Start11 and WindowBlinds plus Incontrol from GRC.
What really pisses me off is that not only did Microshaft not offer a "classic skin", they continually sabotaged attempts by third parties to provide one.
The grey beards I worked with when starting out would talk of sitting in the computer room and being able to tell when it was stuck by the change and regularity of the clicking sounds emanating from the box.
One of the same wise men also said "why don't you get married, why should you be happy?". I have often dwelt on thosevpearls on later life. Actually, the wisest and nicest person there was a lady in her 60s who'd been in IT since year dot. Probably learned more off her about how to be in a team than anyone else
When our uni had a PDP-11/45 running an early version of Unix used mostly by grad students doing stuff with Ingres (a database engine), they had a beat-up radio they tuned to an unused spot on the band and left running at low volume. The computer created radio frequency interference, and the sounds coming over the radio provided clues as to what the computer was doing (and not doing).
I did some RFI debugging when I was writing a keyboard-mods-and-macros TSR in assembly in PC-DOS back in the '80s. My program hooked various things and jumped into various places in the BIOS, so sometimes the machine went unresponsive, and it was slightly useful to know whether it was looping or stuck waiting for an interrupt, which you could distinguish by the sound of the AM interference.
Sometimes I'd turn the radio on while working on school projects in Turbo Pascal, just for the fun of hearing it running the CPU-bound parts.
Anyone recall the "witty" BSOD screensavers.......
Back in my PhD days, an office mate ran some modelling code expected to take a week to run. The box it ran on had a BSOD screensaver, which prompted somebody passing to helpfully reset the box for him by pressing Ctrl-Alt-Delete on day five.
But on a working Windows NT box, didn't control alt delete just bring up the login options or something?
A lot of Linux machines were set to have it reboot the computer though. If it was a Linux machine with a BSOD screen saver, that would not be good.
On the other hand, really that modeling code should be checkpointing its state to disk every so often. Things happen in the timescale of a week. Like somebody tripping the circuit breaker and the power goes, or there's a crash, or something. Checkpointing every so often is not that hard to write and not much of an overhead, and it saves a lot of time if you have to restart the calculation after a problem.
You're assuming that a) the work in question was being run on something other than a bog standard spec desktop PC of the era (and therefore having it running anything exotic like NT would be out of the question) and b) the modelling code had been written by someone sufficiently well versed in good software design principles, or who had enough time to finess the code in such a way given whatever project deadlines they were up against, to have considered adding any sort of checkpointing functionality.
In a university environment, given the likely era we're talking about (i.e. back when screensavers like that were popular), it's probably somewhat unsafe to assume either of those two things would be true - when I was a research student in the mid 90s, our lab PCs were mostly still just consumer-spec Win3.1 boxes, with a few Win95 ones starting to appear later on, and whilst we had a basic level of programming teaching from our time as engineering undergrads, that was just aimed at making sure we knew one end of a compiler or assembler from the other, it most assuredly didn't cover anything even remotely advanced like writing robust code.
Alt-SysRq-B will instantly reboot many Linux boxes (depending on the kernel configuration). You can achieve a more or less controlled reboot by remembering the word BUSIER, but using it backwards, i.e. by pressing Alt-SysRq-R, Alt-SyRq-E ... Alt-SysRq-B. Leave a little time between each invocation for the kernel to do its thing if you're not working from a console.
All you need to know: Documentation for sysrq.c
Ctrl-Alt-Del has been the Windows SAK (Secure Attention Key) sequence since at least NT 3.51, yes. It still is, if you configure (desktop) Windows properly.1
The SAK is an important security feature, required by TCSEC C2, which is why it's widely ignored and disabled, as security features generally are (because people are idiots). Some other OSes, such as AIX in the days of desktop RS/6000s, offered SAKs, either by default or as a feature you could enable.
Presumably the machine in the GP anecdote was not running Windows NT.
1For headless installations of Windows Server, there's no SAK because there's no console, obviously.
In Win3.x there was a .ini file line that allowed you to change the colour of the screen of death.
That command was carried to the Win9x
So, most users of indows (as the NT branch users were the minority until WinXP) had a multicoloured Screen of Death without knowing it.
Anon because I don't want to embarrass my previous employer.
About a decade or so ago, I was working for a large IT company, and we had a technology that - without going into specifics - could help with recovering from fleet-wide system failures, including Blue Screens.
I was part of the marketing team; before you throw fruit at me, I emphasize that I was on the technical side of things, not the whalesong-and-joss-sticks side.
As part of my efforts, I created demos of the technology in action. Live demos, using real hardware and software, not some video animation or mockup. This meant I had to have a way of triggering a Blue Screen on-demand, so I wrote a small program that, running with admin rights, did nothing more sophisticated than traverse the Windows process list, kill -9'ing each one in turn. This naturally caused the metaphorical mine tunnel ceiling to fall in and a Blue Screen was the instant result, allowing our technology to roll into action and recover the system.
The demo was well-received, and led to a lot of customer interest and lucrative sales... until one day I was called to a meeting with senior management and (politely, reluctantly) told that I had to withdraw the demo and block our Field Sales teams from using it. The reason given was that our CxO team had been told by senior Microsoft people that the latter really didn't like our mutual customers being reminded that Windows could Blue Screen - at the time, Chrome/Android/IOS/Mac OS were ascendent, and the perception that MS were having to counter was that those other OS's "didn't crash [sic]".
And so I had to revert to less drastic demos!
Yeah. It's hardly surprising that an OS can be taken down by terminating privileged system processes, if you're in a position to do so. But I can see Microsoft wanting to pretend otherwise.
I used to work frequently on a complex distributed-system product that included a number of processes that (in some configurations) had to run as privileged Windows system services. For Reasons, they had to be debugged with Microsoft Venomous Studio. I was in the habit of starting VS as Administrator (necessary to debug processes running under another account), accelerator-keying into Debug > Attach to process, typing the first few letters of the name of the process I needed to attach to, and hitting Enter, all without looking. Then typically I'd break into it to examine the call stacks for each thread and so on.
One time I fat-fingered the process name and attached to CSRSS instead. You really do not want to attach a debugger to CSRSS and then stop it so you can look at its call stacks. That turns out to be a very quick way to take Windows down — at least for whatever I was running at the time (probably Win 7).
Fortunately, I long ago learned to save everything early and often, so this sort of thing was just an aggravation.
When the code trapped out on an older system you got a core dump where the entire working memory was written to a file along with the machine registers. This is all a suitably motivated programmer needs to find the problem although it could be tedious work (people would print the core dump out and trace back everything manually). A modern debugger does the same thing, its just a lot more selective about what it displays and includes a raft of convenience functions (like automatically associating symbols with memory locations....luxury!!).
This isn't a whole lot of use for a typical user so when you get the trap the only thing you can do is restart the system (and keep your fingers crossed).
Nowadays a core dump is more associated with the inevitable aftereffects of an ill advised curry after a very long night out, at least it feels that way.
Still, it's nice to have something to fall back onto when your system borks, because otherwise you're wondering (a) what happened and (b) if it could happen again. The latter is a very uncomfortable situation to be in.
As I explained to non-techie Unix users in the 1990s why I couldn't just 'look at the core file [on a 64 MB system] to figure out what went wrong', "It's like having every single fragment of a crashed airliner -- spread out over several square miles -- to look at."
It was a commercial app to which I didn't have access to the source, and the executables had been stripped "to protect our proprietary information."
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
