The concept of an "illegal instruction" is simply bad computer jargon for the home user. In the same way that many users get confused with OK / Cancel dialog boxes (warranting the more politically correct Yes / No dialogs), this is a case of a one-time bad choice that has stuck around for years. Granted, Mac OS uses the same terminology as Windows, but only when looking through the eyes of MacsBugs (the Macintosh PPC debugger). Many times while writing an application on that platform have I seen the white register screen and in little red text PowerPC illegal instruction at (memory value). You can then manipulate the stack, and perform a few other functions before the program is killed, and the health of the OS left to chance.

In response to Whizkid's writeup, you are seeing this through the eyes of a consumer, with the knowledge spin of a developer who hasn't thought out the full reason behind this practice. To a software engineer, you want to know whenever a program dies, for any reason. For instance, closing a window, in Windows, does not actually begin any shutdown procedure. There are many cases of programs in Windows, Unix, and MacOS that remain resident, even though there is no active UI up. Clicking on a close button simply sends a WM_CLOSE message to a window. Windows as the OS and GDI as the drawing manager, can infer nothing about a program, just because you've closed a window. Maybe it still wants to run in the system tray, maybe it's a memory-resident daemon that spawns a dialog, or maybe it's going to open up a new window at some point.

Believe it or not, Windows is doing the right thing here by showing you the message. When you see the message twice, you are likely witnessing the death of numerous threads of an application (or of a COM object instance and it's associated server), largely due to another thread suddenly not being there. As a developer, with a debugger on the system, I can click cancel (to debug), and see exactly what went wrong in Visual Studio, or any other program that will give me a backtrace and a symbols dump. This is incredibly important for anyone writing software on a varied platform like Windows. The bare registers are much harder to use (some people I knew could make sense of them), but the memory location is most important. A programs that abruptly reports its untimely death to the user works better from a user information and interaction perspective than something just randomly dying.

  • If you see a crash in x.x at location 0x00000000, this means you've dereferenced a null pointer. Look for somewhere in the code where something is NULL, or you've allocated memory, and not checked to see whether you've actually got the right memory.
  • If you see a crash in x.x at location 0xfeeefeee, or 0xdeadbeef you'll know that you just tried to use memory that has been freed to the system.
Other values can of course mean other things, but it's your code that you need to keep under control. A cause of many many errors in code is binary corruption in the registry (most common in non-NT systems), dll Hell, and corrupted bits from disk damage. There are ways you can control each problem, and keep unexplained crashes off your system (or at least to a minimum). If you are seeing blue screen-esque "illegal instructions", or "Access violations" then it's most likely a driver problem, and you should contact your OEM vendor. So, as it stands, this message is a double-edged sword. For developers, you want to see it before a customer does. If a customer does see it, you want to give them the Customer Diagnostic tools (Windows 2000 CD2) to get a symbolic dump of the heap, a backtrace, and other items (gdb gives you this as well), if you chose to spot debug it. Windows is only doing what the unwitting programmer told it to do, and that is fail. Your IE is crashing because something is wrong with your history, cache, cookies, registry, or other binary component. With continuing developments and improvement in overall stability of consumer-end systems, these messages will persist with two-bit software, but you will see them fade away in larger-end projects. As always, contact your vendor, but many times, they will go through, what I've just mentioned. Preserving system health by careful choices as to what you install is the key to a stable computing experience.