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.
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.
- To keep the registry clean, there are several programs available. One is Norton, which has it's own set of problems and hell, and another is Microsoft's own RegClean (even though I wouldn't use it past Windows 98). In Windows Millennium, PC Health is supposed to take care of the registry, and Windows NT has Fort Knox permissions and protection upon it and all of it's keys. Basically, with Win9x you always run the risk of registry problems, so my best suggestion is to upgrade to NT. There are various registry watchers that can tell you when something is being looked at in the registry by a particular program. You may want to try backing up and deleting those problematic keys, as many programs regenerate missing keys. Also, avoid lots of shady third-party software. If you run a system of ALL Microsoft stuff out of the box, it all works great. Why? Because everyone in Redmond is using that same thing, and they'd spot bugs immediately. Highly-tested software (especially in the software configuration department) is very crucial to a stable PC.
- Avoiding dll Hell is usually the job of the programmer, but don't let things install a pile of libraries, every time it dumps items into your system directory (overwriting other versions of the library). There is little you can do, but Windows 2000 manages this problem much better. Always run the most updated version of a program. Newer installers (such as Vise, the new InstallShield, and Windows Installer) take care to manage Dll Hell a little better. Calling to the wrong version of a dll (whether it be the MFC dll, [VB runtimes, Winsock, etc) is very bad, and will cause considerable trouble.
- Binary disk corruption is somewhat rare, but does happen to people (if the disk is writing while the power goes out, you shut it down unexpectedly, etc). Be vigilant with your disk maintenance, and things will be all right. Microsoft provides Scandisk for Windows (scandisk.exe for DOS, and scandskw.exe for Windows). Windows NT comes with chkdsk, and you can schedule them on a reboot.
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.