Giving a "g" (go) command from the debugger with the ip (instruction pointer) pointing to anything other than a valid code sequence with a normal termination at the end will and should crash any system not running in protected mode, be it a Pentium (with the bug) or a Pentium Pro or Pentium II (both of which do not have the bug). The difference here, which is difficult to fully explain unless you are moderately knowledgeable, depends on your operating system and whether it uses protected (WinNT) or unprotected (Win95) mode.
Under Windows 95, even if the "bug" did not exist, the system would be expected to crash most of the time, because even though the processor was not locked up, it would be executing random memory contents, and this would result in a crash the vast majority of the time.
Under Windows NT, the same thing would happen to the active task (process, user [VERY loosely]), however if the processor itself was not locked up it should "catch" the wayward process and terminate it, with other tasks/processes/users not being adversely effected. If, however, the processor itself "locks up", then EVERYTHING on that computer will stop cold until it is rebooted.
Since I presume that you are running Windows 95, it's not surprising that your system appeared to crash even though it is a PII, which does not have the bug. The reason is that it can be very difficult to distinguish between a "software crash", in which the system becomes totally non-responsive even though the processor is still running, and a processor lockup, in which the processor actually stops running. That's why this bug is completely and totally irrelevant to anyone who is not running a protected mode operating system (Windows NT, for example). It requires the execution of invalid opcodes, which would be EXPECTED to send the running task/user/process "off into the weeds". What is not expected is that other processes (essentially, other users) would be impacted as well.
Barry Watzman |
