diff --git a/modules/pcjs/lib/x86.js b/modules/pcjs/lib/x86.js
index 7b23e50f0..2d884e780 100644
--- a/modules/pcjs/lib/x86.js
+++ b/modules/pcjs/lib/x86.js
@@ -230,7 +230,7 @@ var X86 = {
      * Interrupts beyond 0x10 (up through 0x1F) are reserved for future exceptions.
      *
      * Implementation Detail: For any opcode we know must generate a UD_FAULT interrupt, we invoke opInvalid(),
-     * NOT opUndefined().  UD_FAULT is for INVALID opcodes, Intel's choice of "UD" notwithstanding.
+     * NOT opUndefined().  UD_FAULT is for INVALID opcodes, Intel's choice of term "undefined" notwithstanding.
      *
      * We reserve the term "undefined" for opcodes that require more investigation, and we invoke opUndefined()
      * ONLY until an opcode's behavior has finally been defined, at which point it becomes either valid or invalid.
diff --git a/modules/pcjs/lib/x86op0f.js b/modules/pcjs/lib/x86op0f.js
index 782c12e51..bddeb2601 100644
--- a/modules/pcjs/lib/x86op0f.js
+++ b/modules/pcjs/lib/x86op0f.js
@@ -1332,6 +1332,24 @@ X86.aOps0F[0x06] = X86.opCLTS;
  */
 X86.aOps0F[0x0B] = X86.opInvalid;
 
+/*
+ * NOTE: Any other opcode slots NOT explicitly initialized above with either a dedicated function OR opInvalid()
+ * will be set to opUndefined() when initProcessor() finalizes the opcode tables.  If the processor is an 80386,
+ * initProcessor() will also incorporate all the handlers listed below in aOps0F386.
+ *
+ * A call to opUndefined() implies something serious has occurred that merits our attention (eg, perhaps someone
+ * is using an undocumented opcode that we haven't implemented yet), whereas a call to opInvalid() may or may not.
+ *
+ * For example, when Windows initializes in protected-mode, it sets a DPMI exception handler for UD_FAULT and
+ * then attempts to generate that exception with undefined opcode 0x0F,0xFF.  Apparently, whoever wrote that code
+ * (davidw?) didn't get the Intel memo regarding the preferred invalid opcode (0x0F,0x0B, aka UD2), or perhaps Intel
+ * hadn't written that memo yet -- although if that's the case, then Intel should have followed Microsoft's lead and
+ * selected 0x0F,0xFF instead of 0x0F,0x0B.
+ *
+ * In any case, this means we need to explicitly set the handler for that opcode to opInvalid(), too.
+ */
+X86.aOps0F[0xFF] = X86.opInvalid;
+
 if (I386) {
     X86.aOps0F386 = [];
     X86.aOps0F386[0x20] = X86.opMOVrc;
diff --git a/modules/pcjs/lib/x86ops.js b/modules/pcjs/lib/x86ops.js
index a4c7670ac..d78013dd2 100644
--- a/modules/pcjs/lib/x86ops.js
+++ b/modules/pcjs/lib/x86ops.js
@@ -4017,7 +4017,6 @@ X86.opGRP4w = function GRP4w()
 X86.opInvalid = function opInvalid()
 {
     X86.fnFault.call(this, X86.EXCEPTION.UD_FAULT);
-    this.stopCPU();
 };
 
 /**