While working on an unrelated problem, I noticed a strange behavior of one of my OS/2 VMs running OS/2 Warp 4.52. To cut a long story short, if an unhandled floating-point exception occurred in a DOS window (VDM, or Virtual DOS Machine) while executing real-mode code, the DOS box would crash because it would try to execute an invalid instruction. The IRQ13 (INT 75h) handler provided by the BIOS would run, and then execute an INT 02h instruction (for compatibility with old PCs). But interrupt vector 2 pointed to a place in the middle of the VDM’s conventional memory that wasn’t even allocated. It should be pointing to the BIOS and execute harmless code.
I quickly realized that only one of several very similarly configured VMs did this. At first I suspected a problem with the way the DOS box in the troublesome VM was set up, but that wasn’t the case. The OS version wasn’t it either. What’s more, the VDM was simply reflecting the contents of physical memory (the former real mode IVT at physical address zero)… and the IVT was modified very early in the boot, before even showing the OS/2 boot logo or boot menu.
Finally realization dawned: The OS/2 kernel debugger was doing this, and that’s why most of my VMs didn’t have the problem. But why would this happen at all? Continue reading





