In Windows 3.X we had multiple type of error dialogs that could be displayed:

Application crash:

enter image description here

Application error that could be recovered:

What did the Ignore button do in Windows 3.1 when an application encountered a general protection fault?

enter image description here

System error (by the lack of a better name):

(simulated by pressing Ctrl+Alt+Del)

enter image description here


Were text mode errors more severe than graphical mode errors ?

Or was the type error dialog being shown not related to its severity level at all?

  • It's not really clear what yo're asking. Would you mind to elaborate what you're looking for? (I assume a 'Because the programmer made it that way' isn't what you're looking for, or is it?
    – Raffzahn
    Jul 23, 2019 at 20:30
  • I have edited my question, hope it's clearer now. Basically I am trying to understand when and why one or the other were shown (text or graphical), generally when you'd get a text mode error you were good for rebooting the computer for proper operation :)
    – aybe
    Jul 23, 2019 at 20:38
  • Oh, ok, that's quite simple: It's not so much about the severity, but if the system was able to handle it in context of a user processes or not. Some of them (like your example) have been handled in later versions in a more beautiful way, but the topic stays.
    – Raffzahn
    Jul 23, 2019 at 20:46
  • It should be noted that "recovered" (both in your use and the article linked) is very misleading. Something has gone wrong, and something is almost guaranteed to have the wrong value afterwards: you've ignored the problem, not recovered from it. You should not attempt to do more than try and save any pending work (in, as the dialog notes, a new file, since the error may mean you'll be saving garbage and you don't want to overwrite the original file that might still be valid (although out of date)).
    – TripeHound
    Jul 25, 2019 at 11:07
  • 1
    Raymond Chen wrote another article about this: devblogs.microsoft.com/oldnewthing/20240116-00/?p=109274
    – Ray
    Jan 17 at 7:50

5 Answers 5


Were text mode errors more severe than graphical mode errors ?

It's not so much about the severity, but if the system was able to handle it in context of a user processes or not. Some of them (like your example) have been handled in later versions in a more beautiful way, but the topic stays.

Or was the type error dialog being shown not related to its severity level at all?

More indirect, as severe errors are often errors not really related to a certain application but the core system - thus usually resulting in a blue screen.

Blue screens also differ not only in their source, but also by operating different than any message box. When a blue screen is displaye, the whole system is halted. This is important so no process may change the sate or continue harmful action.

When message boxes are displayed, basic OS operation and background processes are not halted. All they can do is halting UI interaction by being application or system global, thus preventing any user input for an application or the system at all - except for the message box that is.


The premise of your question is somewhat incorrect, though it's a common misconception by people conflating how Windows 3.1 worked and how Windows 95 worked.

In Windows 3.1, if an application had an error, it would show the graphical box you included, and as it says in the Raymond Chen article you linked that box sometimes had an option to Ignore the error.

You show the screen that one gets when hitting Ctrl+Alt+Del, but that's really just the Ctrl+Alt+Del screen. That's not an error screen, it's a tool used to help you stop a hung program.

There were some other "blue screen" messages, particularly for system messages that needed to coordinate between the DOS VMs and the Windows applications, such as handling device conflicts when more than one application was trying to use a serial port. You can see some examples in another Raymond Chen post, "Steve Ballmer did not write the text for the blue screen of death". These were messages not really specific to an application, but regarding sharing the system resources between them and prompting you how to handle them. However, as that article says, Windows 3.1 didn't really have a "blue screen of death":

If an MS-DOS application crashed, you got a blue screen message saying that the application crashed, but Windows kept running. If it was a device driver that crashed, then Windows 3.1 shut down the virtual machine that the device driver was running in. But if the device driver crashed the Windows virtual machine, then the entire virtual machine manager shut itself down, sometimes (but not always) printed a brief text message, and handed control back to MS-DOS. So you might say that it was a black screen of death.

To answer your question, the presentation of the message wasn't related to the severity, but whether it was an application-level or system-level message.


Most of all, the form of the message reflects the underlying architecture of Windows 386 Enhanced mode.

Enhanced mode Windows kernel consists of two mostly independent layers. I am going to refer to them in this answer as the ‘supervisor’ and the ‘hypervisor’, although those terms are somewhat anachronistic: they were not used at the time to describe the design of Windows, although the terms already existed back then.

The supervisor is pretty much Standard mode Windows, and it handles most of what we think of as ‘Windows’ proper: starting Windows applications, scheduling them, drawing on the screen and handling application crashes. Displaying messages informing of the latter is the responsibility of an internal API call named SysErrorBox; other than being modal to the entire system, the message box is a completely ordinary window, handled by the same message loop architecture as every other window in the system.

Screenshot of a white dialog box in Windows 3.11 with the title ‘Hello’, message ‘This is a SysErrorBox!’, and a single OK button. Underneath, Borland Pascal 7 for Windows IDE dislaying the source code of the program which produced it.

As for the distinction between error boxes that contain the ‘Ignore’ button and those which don’t, the blog post linked in the question already explains it: whether the button appeared depended on whether the crash handler is able (and willing) to skip the particular instruction which triggered the crash. Either of these can result from a General Protection Fault (which usually means memory corruption), so they are about equally severe. The ‘Ignore’ feature appeared in Windows 3.1 (in earlier versions, all crashes were unrecoverable) and existed mostly to give the user a last-ditch option to attempt to save their data and exit the program relatively gracefully. The error message instructed the user to save their data in a new file to prevent overwriting a known-good file with a potentially corrupted version (as it might very well be, given that it was written by an application in a corrupted state).

The hypervisor layer is the Virtual Machine Manager: its purpose is mainly to allow running DOS programs under Windows. Both the supervisor and each DOS box runs in a separate virtual machine; the virtual machine which runs the former is called the System VM. The VMM decides how those virtual machines map to physical hardware: it may, for example, direct writes to screen memory to update the contents of a DOS box window. Unlike the supervisor, the VMM does not understand how to draw on the screen and only knows enough about devices to know how to dispatch signals from them to the correct virtual machine. Most screen operations are handled by the virtual machines themselves; the VMM only contains just enough display drivers to be able to switch the video hardware to text mode and back. And so, when the VMM needs to communicate something to the user without the help of the System VM, that’s exactly what it does.

As others have already pointed out though, Windows 3.1 does not use full-screen text mode messages to inform of crashes: the actual Blue Screen of Death did not appear until Windows 95. An outright crash in the VMM would take the entire system down and return the user to a DOS prompt. In Windows 3.x, messages from the VMM usually relate to the rather specific job it performs: for example, it informs the user about hardware conflicts and prompts the user to switch floppies when performing dual floppy drive emulation on a single-drive system. The VMM also includes a rudimentary software hang detector: pressing CtrlAltDelete prompts the VMM to check for a Windows process stuck in a message loop and offer to forcibly terminate it. This results in the blue screen prompt featured in the question.

Blue screen prompts can be, among other causes, triggered by VxD drivers through the VxD service SHELL_SYSMODAL_Message, although that is not quite its exact purpose — when invoked on behalf of a DOS box, it may try to display a regular message box instead, by handing over the request to the System VM.

Windows 3.11 showing a blue screen message, with the title ‘SHELL_SYSMODAL_Message’ and the lyrics to Rick Astley’s ‘Never Gonna Give You Up’ as the main message body. At the bottom, there is a prompt ‘Press Y for Yes or N for No’; at the position of the caret, the letter N appears.

Windows 3.11 showing the same message as above, but in a graphical message window instead: instead of a text prompt, there are graphical buttons ‘Yes’ and ‘No’, with the mouse pointer hovering over ‘No’. In the background, an MS-DOS Prompt window is seen, running the command ‘rickroll’.

  • You could also use MessageBox(..., MB_ICONHAND || MB_SYSTEMMODAL) flags to display a SysErrorBox.
    – Yuhong Bao
    Mar 2, 2021 at 2:24

A General Protection Fault means the application tried to access memory that was not allocated to it. It's a user mode crash. The OS can recover from this by halting the application.

A bluescreen is a kernel mode crash. Something in the kernel itself (often a driver) or faulty hardware did something wrong in a way from which the OS cannot recover. Of the two types of crashes, this is the most severe.


There are three types of error in your question. I'll cover them in least to most severe.

enter image description here

This is an error that allows the application to continue. An example might be an attempt to access a resource that it does not have access to, such as a previously released file handle. The error can be ignored and the application can continue, but the effects are unpredictable which is why it advises you to save your work.

enter image description here

This type of error is more severe, and prevents the application continuing. For example, the application's executable memory may have been corrupted, or its program counter been set to a bad address so there is no way to know where to continue running from. In that case, the application must be shut down.

enter image description here

This message is displayed when the user user pressed CTRL-ALT-Delete, which was used to kill and application that had locked up, but no applications were locked up as far as he system is aware. This can happen when a part of the OS itself locks up, or a vital service like a disk driver or filesystem handler. When that happens it is often impossible to save work or restart the computer normally, because those actions all end up waiting for the locked up component.

As such, the user's only choices are to return to Windows and continue waiting, or force a restart without a safe shutdown first.

  • I'd totally forgotten about the first two. Are the first two technically the windows debugger (I'm not sure what the proper name is) trapping an uncaught exception and then asking how to handing it? Or is it actually error handling in the api itself? Oct 7, 2020 at 5:20
  • ‘This type of error is more severe’ — no, not really. As the linked blog post explains, either can result from a GPF (usually memory corruption), so they are about equally severe. It’s just that Windows had a feature that in some cases enabled applications to limp along long enough to allow the user to close them semi-gracefully. Oct 11, 2020 at 5:39

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .