Sure, all of you have seen this ubiquitous error message, and cursed many times at the computer because of it. The problem is, what did the computer do that was so illegal? I took it upon my duty to find out.

When you get your error message, it usually looks like this:

This program has performed an illegal operation and will be shut down.
If the problem persists, please contact the program vendor.

Not only is this claim confusing, it is also ludicrous. The problem has persisted about 4832 times for Internet Explorer, but I don't think many people contact Microsoft. We just grin and bear it, or more likely, say "WHAT THE FUCK IS WRONG WITH YOU?".

Now to find out what my computer did that was illegal. Since my computer seems to do the illegal operations everyday without getting caught, I can only assume that it's only illegal if it is caught by the Internet Gestapo. They track the phone lines everyday, looking for people using the Internet, and give them the error just for the hell of it. They're sadistic.

So, in conclusion, after studying my computer for many days, I can honestly say that getting the error message is completely random.

And this isn't even looking at the fact that when you click on details it says:
"err on jfdkj.dll for invalid cookie reciept, at BGFIDHGWIYSFEUOGHAEOUGHUAOHGB;O AUERBGIOANWEIFHNIWEOBF;I AWEBFUOEAWB;FWA;.GEFNBAWI.OLEBG.WAEB HILG HAIURGBLIUAWEBFL"
Some things were not meant to be solved.

This message would not bother me under ordinary circumstances, while the program is running. I mean I can hardly blame the OS for a program trying to access some memory it does not own.

What really gets to me is that I often get this message several seconds after I have instructed the software to shut down. I mean, come on, Windows knows the program is being shut down because, after all, Windows software reacts to the shut down request by sending itself a Windows system message.

It would seem logical that if I have requested a program shut down, I don't need to be told it is going to be shut down. Hey, the problem is with some memory error in the computer, not a memory error in my head.

Secondly, this message drives me crazy when I get it twice (or more times) in a row for the same program. I already know from the first message the program messed up, and I have resigned myself to it by clicking OK, so why tell me again and again. Just shut it down already, and shut up!

Either problem could easily by solved by using a flag. Dear, Microsoft programmers, it appears the concept of flag is new to you, so here's an explanation: You reserve either a bit or a byte (or whatever size, but a single bit is enough) of memory whenever you load a program. This bit/byte/whatever is the flag. Now, you set the flag to zero initially (the flag is off, you know, just like keeping a real-world flag lowered).

When the program sends itself the message to quit, the system software simply needs to change the value from 0 to 1. That is, the flag is on (you know, as if a real-world flag were raised). Get it so far? Good!

Now, when an exception occurs, let your exception handler check the value of the flag. If it is zero, pop up that message box about the program being shut down and set the flag to one (this mind boggling trick will prevent you from popping it up twice).

If, on the other hand, the flag is already set when your handler starts (i.e. its value is not zero), just kill the program without popping up that message box. Got it? Excellent!

Oh, yes, Microsoft, you now need to send me $10,000,000 flat, plus $2 (US currency) for every copy of Windows you sell hereinafter. And don't even think about patenting this revolutionary new idea!

And because so many people were scared that their computer was breaking the law by performing an illegal operation, this wondrous message has been replaced in Windows 2000 Service Pack 2 and Windows ME.

You now get a cute, friendly message informing you: 'Internet Explorer has encountered a problem, and must close.' Any extremely important reports you were writing have most definitely been lost forever.

Please sigh, and continue using shoddy badly programmed pieces of software.

OK, The part in quotes is true, but I can't remember the rest, since I only installed SP2 yesterday...

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.

Log in or register to write something here or to contact authors.