jeffpar / pcjs

The original IBM PC and other machine emulations in JavaScript
https://www.pcjs.org
Other
809 stars 122 forks source link

MSWindows 95: Trying to trace a DPMI program with lDebugX crashes the OS #75

Open ecm-pushbx opened 1 year ago

ecm-pushbx commented 1 year ago

Running https://www.pcjs.org/software/pcx86/sys/windows/win95/4.00.950/

We get an error as shown below, when a simple test program tries to enter DPMI protected mode. It reads:

MS-DOS Prompt

This program has performed an illegal operation and will be terminated. Quit all programs, and then restart your computer.

If the program consistently encounters problems, click the Start button, then select Help, Troubleshooting, and 'If you have trouble running MS-DOS programs'.

[OK] [Details>>]

The program encountered an invalid page exception.

Fault location: 0028:C0236811 Faulting component: DOSMGR(0E) + 00000ED5 Interrupts in service: None

Screenshot showing the error:

Screenshot at 2023-08-13 21-46-51

The dpmimini program is included in the disk image https://pushbx.org/ecm/test/20230813/bcdebugx.img which is unlocked on the server for use as a remote disk for PCjs. The source of the program is in https://hg.pushbx.org/ecm/dpmitest/file/845e876b561e/dpmimini.asm

If I run my debugger, lcdebugx.com dpmimini.com then on the first trace step (T command) it informs me that "DPMI entry cannot be hooked!" which is expected on MSWindows 4. However, tracing into the DPMI entrypoint (call far [bp + 00] instruction at offset 0143h) I get an address of FCB8:2F97 with the instruction bytes 63, 38 that disassemble as arpl [bx + si], di. If I try to trace this, the machine crashes in the same way as for running only dpmimini. The error message is exactly the same.

ecm-pushbx commented 1 year ago

It is possible that arpl is intentionally used as an instruction that causes a fault in V86 Mode: https://www.felixcloutier.com/x86/arpl says that it should #UD in V86 Mode. So this may be not the cause of the error.

ecm-pushbx commented 3 months ago

My DPMI test program was in error, it frees and zeroes the environment segment at word [PSP:2Ch] but MSWindows expects this field to be nonzero upon entering DPMI Protected Mode. With this part commented out the DPMI mini program runs fine on its own.

However, when I try to trace the arpl instruction used to enter PM in either lCDebugX (both /D+ and /D- mode) or lDebugX then Windows crashes. Briefly I get a mostly black screen with the outlines of the MS-DOS prompt window in white, then the machine falls back to a memory test apparently done by the ROM-BIOS, which emits some beeps. After pressing F1 several times the machine reboots.

I tested a similar program on an MSWindows 98 SE running on a physical 686 machine and it works just fine after the modification to dpmimini.com. (I didn't test the exact same program on both machines yet.)