Friends have had a lot to say about the frequency with which I've been experiencing the Windows NT blue screen of death (BSOD). Many politely suggest that I wipe Windows NT off my system and switch to this or that other operating system. Others were less polite (read: flame), telling me the BSOD is an indication of a hardware problem and advising me to stop complaining about NT and fix my hardware.
When I'm battling DLL hell, registry errors, or the dreaded BSOD, I confess I would like nothing more than to wipe NT off my system and banish it forever. But I don't.
I could explain this contradiction by pretending that I'm sticking with NT only because my job requires that I look at a lot of Windows NT software. That's true. But there are some 32-bit Windows applications that I honestly like to use. And although Windows NT may have some major architectural flaws, given the choice between running these applications on Windows 95 or Windows NT, I'll take NT any day.
As for the remaining crowd, a BSOD can occur for a wide variety of reasons other than hardware configuration conflicts, failing hardware, or bad memory. A BSOD can result from a wide variety of problems including kernel bugs, memory resource depletion, a corrupted registry, driver bugs, or even the inability of the OS to handle an unexpected condition. The list of bug codes at the URL support.microsoft.com/support/kb/articles/Q103/0/59.asp will give you an idea of just some of the potential problems that lead to a BSOD.
The reason most people assume a BSOD is hardware-related is because errors that cause a BSOD often occur in hardware drivers. This is true whether the fault is due to hardware failure, misconfiguration or a bug in the driver. Indeed, this is why you see the BSOD more often in NT 4.0 than NT 3.51. The Windows NT 3.51 kernel was protected from more drivers than is NT 4.0's. Microsoft now allows display drivers to have unrestricted access to critical parts of the system, for example.
When a hardware driver touches part of the system it isn't supposed to access, the damage to the system is done before Windows NT can isolate the error, prevent it, or correct it. So Windows NT figures it is safer to crash with a BSOD than to continue running. As odd as it sounds, this is typical behaviour for an operating system. Many operating systems are better than Windows NT at protecting themselves from runaway hardware drivers, but they react the same way when the rules are broken.
Aside from the fact that hardware isn't always involved, the problem I have with the "fix the hardware" answer is that it implicitly excuses Windows NT from responsibility when a BSOD occurs, as if one shouldn't expect the operating system to handle hardware-related problems. I, for one, expect more from an operating system than that. And I know from experience that more is possible.
For example, I can get a BSOD simply by accessing (or, in some cases, simply inserting) any of three improperly written CD-Recordable disks that I had.
The system automatically tries to read the CD table of contents, but never succeeds. The result? BSOD. (Yes, I have tried SCSI card reconfiguration, new drive settings, latest drivers, hot-fixes, and so on.)The same disks cause Windows 95 to hang hard. But of the three disks that neither Windows 95 nor Windows NT can handle, Linux mounts one disk successfully but, as one would expect, it fails to read the improperly written files. The second disk causes Linux to report that the SCSI device isn't responding. When I mount the third disk, Linux resets the SCSI bus. I issue a kill command to stop the mount process, then I continue working as usual.
When I need something done, what matters to me is what works and what doesn't. In many cases, Linux works and NT doesn't. But to those defensive souls who want to feel better about NT by blaming the BSOD on hardware, my return advice is to relax. I don't want a Linux-only world any more than I want an NT-only world. When I complain about NT, it's because I want Microsoft to fix it, not eliminate it.
Former consultant and programmer Nicholas Petreley is editor in chief at NC World. Reach him at firstname.lastname@example.org