Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
ecm-pushbx opened this issue Aug 13, 2023 · 2 comments

Comments

@ecm-pushbx
Copy link

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
Copy link
Author

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
Copy link
Author

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.)

@ecm-pushbx ecm-pushbx changed the title MSWindows 95: Trying to start a DPMI program crashes the DOS window MSWindows 95: Trying to trace a DPMI program with lDebugX crashes the OS May 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant