Back to home page

DOS ain't dead

Forum index page

Log in | Register

Back to the forum
Board view  Mix view

[BUG] ESP=0 | push | TripleFault | BOOM! | inside HDPMI32 ? (DOSX)

posted by DOS386(R), 10.01.2008, 01:51

Japheth wrote (IIRC, something like, in old, now deleted :no: forum) :

> The main benefit of running a DPMI application in Ring3 rather than Ring0
> is, that if a dead loop with decreasing stack pointer occurs (very stupid
> and very popular bug), in Ring0 it unavoidably runs into a TripleFault,
> while with application in in Ring3 the DPMI host easily can clean up the trouble.

I found a very interesting (critical/criminal) BUG in Ladsoft's INFOPAD , occurring if an external DOS based DPMI host on "raw" is present. CWSDPMI raises a PageFault - see shot:

[image]

Done in BOCHS (2.3.0). In BOCHS I could type the "dir" after, but didn't work, natively there is a hard freezer - no chance to type anything.

With HDPMI32, the bug becomes even more mallicious :clap: :

========================================================================
                        Bochs x86 Emulator 2.3
              Build from CVS snapshot on August 27, 2006
========================================================================
00000000000i[MEM0 ] 32.00MB
00000000000i[MEM0 ] rom at 0xffff0000/65536 ('BIOS')
00000000000i[MEM0 ] rom at 0xc0000/38400 ('VGAB')
00000480000i[WGUI ] dimension update x=720 y=400 fontheight=16 fontwidth=9 bpp=8
00000778154i[BIOS ] ata0-0: PCHS=59/16/63 translation=none LCHS=59/16/63
00154790896i[CPU0 ] can_push(): expand-up: SP > limit
00154790896i[CPU0 ] decrementESPForPush: push outside stack limits
00154790896i[CPU0 ] can_push(): expand-up: SP > limit
00154790896i[CPU0 ] can_push(): expand-up: SP > limit
00154790896i[CPU0 ] protected mode
00154790896i[CPU0 ] CS.d_b = 32 bit
00154790896i[CPU0 ] SS.d_b = 32 bit
00154790896i[CPU0 ] | EAX=00000000  EBX=00000000  ECX=00000000  EDX=00000000
00154790896i[CPU0 ] | ESP=fffffff8  EBP=00000000  ESI=00000000  EDI=00000000
00154790896i[CPU0 ] | IOPL=3 id vip vif ac vm RF nt of df if tf SF zf af pf CF
00154790896i[CPU0 ] | SEG selector     base    limit G D
00154790896i[CPU0 ] | SEG sltr(index|ti|rpl)     base    limit G D
00154790896i[CPU0 ] |  CS:0020( 0004| 0|  0) ff801000 00006787 0 1
00154790896i[CPU0 ] |  DS:00e7( 001c| 1|  3) 00000000 000fffff 1 1
00154790896i[CPU0 ] |  SS:0028( 0005| 0|  0) 00026380 000ffffe 1 1
00154790896i[CPU0 ] |  ES:00e7( 001c| 1|  3) 00000000 000fffff 1 1
00154790896i[CPU0 ] |  FS:00ff( 001f| 1|  3) 00000000 0000ffff 0 0
00154790896i[CPU0 ] |  GS:00e7( 001c| 1|  3) 00000000 000fffff 1 1
00154790896i[CPU0 ] | EIP=000000b8 (000000b8)
00154790896i[CPU0 ] | CR0=0x80000031 CR1=0 CR2=0x00000000
00154790896i[CPU0 ] | CR3=0x01fff000 CR4=0x00000200
00154790896i[CPU0 ] >> push ds : 1E
00154790896e[CPU0 ] exception(): 3rd (12) exception with no resolution, shutdown status is 00h, resetting
00154790896i[SYS  ] bx_pc_system_c::Reset(SOFTWARE) called
00154790896i[APIC0] local apic in CPU 0 initializing


Seems that something (damaging HDPMI code in low memory ?) pushes HDPMI into such a self-destructive activity :clap:

It is a bug a INFOPAD, but posting here because 1st CC386 forum is almost dead and 2nd it's a very interesting DOSX/DPMI issue :lol3:

Any ideas what could be the reason of the bug ? Low memory corruption ?

No bug symptoms without CWS/H-DPMI, no bug symptoms with EMM386.

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

 

Complete thread:

Back to the forum
Board view  Mix view
15192 Postings in 1365 Threads, 250 registered users, 13 users online (0 registered, 13 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum