DOS ain't dead - GPF's in Ring 0 || LOGO.SYS || CLOCK

DOS386

09.08.2007, 18:57

GPF's in Ring 0 || LOGO.SYS || CLOCK (DOSX)

Found 2 nice (one is a bit older ;-) ) things coded in FASM:

http://board.flatassembler.net/topic.php?t=6773 LOGO.EXE
http://board.flatassembler.net/topic.php?t=7478 CLOCK

Under HX both fail with crash in DGDI32 ... both on exactly same address ... maybe they could be fixed easily ? :hungry:

Well, 2nd point, slightly worse:

After the thing crashes, and I touch the mouse, I get a GPF in Ring 0 !!! :no: :no:
With hard freezer or some "invalid opcode 2345 4634 5800 0000" junk :no:

YES, I had exactly the same bug with Blo*ek some months ago ... and it was considered as fixed both in Blo*ek AND HDPMI32 ... and now this :no: Regression ? Tested with HX 2.10 -> same bug !!! (some additional missing imports, crash in DKRNL32 instead, but exactly same GPF in Ring 0) ... no regression ... no idea why I never got (and nobody else) this bug before :confused: ... when testing all the not working GUI apps

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

Japheth

Germany (South),
10.08.2007, 07:15

@ DOS386

GPF's in Ring 0 || LOGO.SYS || CLOCK

Post reply

> Well, 2nd point, slightly worse:
>
> After the thing crashes, and I touch the mouse, I get a GPF in Ring
> 0 !!! :no: :no:
> With hard freezer or some "invalid opcode 2345 4634 5800 0000" junk :no:
>
> YES, I had exactly the same bug with Blo*ek some months ago ... and
> it was considered as fixed both in Blo*ek AND HDPMI32 ... and now
> this :no: Regression ? Tested with HX 2.10 -> same bug !!! (some
> additional missing imports, crash in DKRNL32 instead, but exactly same GPF
> in Ring 0) ... no regression ... no idea why I never got (and nobody else)
> this bug before :confused: ... when testing all the not working GUI apps
>

Is this sort of a bug report?

---
MS-DOS forever!

DOS386

10.08.2007, 20:50

@ Japheth

GPF's in Ring 0 || LOGO&CLOCK || anyone can reproduce it ?

Post reply

> Is this sort of a bug report?

YES. Please note that this late bug discovery made me angry ... but not about you of course ;-)

> some minor bugfixes (other thread)

LOGO works now (see shot) ... :-)

CLOCK doesn't (strange, it used to crash on exactly same addr :confused: ), and the GPF's in Ring 0 persists :-(

It's NOT a regression of HX ... and also not because of CTM 2.1 ... no idea why I couldn't discover it before if this bug is really old

Also, the minor MessageBox bug got fixed (see shot) :-)

[image]

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

Japheth

Germany (South),
11.08.2007, 09:52
(edited by Japheth, 11.08.2007, 10:22)

@ DOS386

GPF's in Ring 0 || LOGO&CLOCK || anyone can reproduce it ?

Post reply

> CLOCK doesn't (strange, it used to crash on exactly same addr :confused:
> ), and the GPF's in Ring 0 persists :-(

CLOCK should work now. Very nice app! It's using a non-supported mapping mode, but apparently that doesn't hurt.

btw, there is a bug in the FASM windows includes which confused hx and caused the GPFs: in FASM, there is

CW_USEDEFAULT equ 8000h

OTOH, the MS platform SDK defines it as

#define CW_USEDEFAULT 0x80000000

apparently, windows accepts the 8000h as well (as does hx now), but it is not documented.

--------------------------------------

about the mouse problem: this almost certainly is due to the mouse event proc not being reset. dkrnl32 uses raw DPMI functions to set the mouse event proc, which has the advantage that it works with any DPMI host, but has the disadvantage that the host cannot clear the event proc on its own if an unhandled exception occurs and the host is terminated the hard way ("terminate s/erver").

--------------------------------------

P.S: and please, don't write "GPF's", write "GPFs" instead! Our admin is very sensible and such things do hurt him physically. :crying:

---
MS-DOS forever!

Steve US, 12.08.2007, 13:45 @ Japheth	GPF's in Ring 0 \|\| LOGO&CLOCK \|\| anyone can reproduce it ? Post reply
	> P.S: and please, don't write "GPF's", write "GPFs" instead! Our admin is > very sensible and such things do hurt him physically. I agree with no ' for plurals, but it's widely used by native Anglophones, in respectable publications. rr: Eat something sweet every time you see one of those naughty 's (''s?). You will soon love them.

Berlin, Germany,
12.08.2007, 15:50

@ Steve

GPF's in Ring 0 || LOGO&CLOCK || anyone can reproduce it ?

Post reply

> in respectable publications. rr: Eat something sweet every time you see one
> of those naughty 's (''s?). You will soon love them.

I'll just kick you all out, if I have enough. :wink:

---
Forum admin

DOS386

13.08.2007, 06:44

@ Japheth

GPF's in Ring 0 || LOGO&CLOCK || Clock works || mouse .....

Post reply

> CLOCK should work now. Very nice app! It's using a non-supported mapping
> mode, but apparently that doesn't hurt.

YES :clap:

> btw, there is a bug in the FASM windows includes

:-(

> about the mouse problem: this almost certainly is due to the mouse event
> proc not being reset. dkrnl32 uses raw DPMI functions to set the mouse
> event proc, which has the advantage that it works with any DPMI host, but
> has the disadvantage that the host cannot clear the event proc on its own
> if an unhandled exception

"unhandled" - handled by DKRNL32 instead HDPMI32 ?

> occurs and the host is terminated the hard way ("terminate s/erver").

I didn't terminate the host the "hard way" - the problem occurs after an application crashed in DKRNL32 or DGDI32 and was terminated by DKRNL/DPMILD for this. Drops back to DOS, all seems OK, one can even uninstall/reinstall mouse driver (it "helps" :clap: ), but if I touch the mouse without "fixing" the driver before, the GPF in Ring 0 occurs - then "terminate s/erver" offer appears, but it's too late: either no reaction to keypress at all, or some garbage is reported then (low mem corruption ?) - freezer, reboot :no:

Does this mean the problem is unfixed and not easy to fix ?

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

Japheth

Germany (South),
13.08.2007, 11:54

@ DOS386

GPF's in Ring 0 || LOGO&CLOCK || Clock works || mouse .....

Post reply

> I didn't terminate the host the "hard way" - the problem occurs after an
> application crashed in DKRNL32 or DGDI32 and was terminated by
> DKRNL/DPMILD for this. Drops back to DOS, all seems OK, one can even
> uninstall/reinstall mouse driver (it "helps" :clap: ), but if I touch the
> mouse without "fixing" the driver before, the GPF in Ring 0 occurs - then
> "terminate s/erver" offer appears, but it's too late: either no reaction
> to keypress at all, or some garbage is reported then (low mem corruption
> ?) - freezer, reboot :no:
>
> Does this mean the problem is unfixed and not easy to fix ?

I don't have this problem. Does it appear if HDPMI is installed temporarily (without "-r")?

---
MS-DOS forever!

DOS386

16.08.2007, 10:03

@ Japheth

GPF's in Ring 0 || LOGO&CLOCK || Clock works || mouse .....

Post reply

> I don't have this problem.

Strange :confused:

> Does it appear if HDPMI is installed temporarily (without "-r")

YES. With latest HXRTD, it freezes silently, however, if not resident.

Test:

http://www.unet.univie.ac.at/~a0503736/php/drdoswiki/uploads/Main/X.zip

CRACKED.EXE :lol3:

Re-Uploaded nice P15 shot:

[image]

Less nice shot showing cosmetic mouse arrow bug:

[image]

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

Rugxulo

Usono,
14.08.2007, 00:07

@ DOS386

GPF's in Ring 0 || LOGO&CLOCK || anyone can reproduce it ?

Post reply

> LOGO works now (see shot) ... :-)

Yeah, it apparently works, even in DOSBox 0.71, with the latest HXRTD.ZIP.

However, I wish people would mention if "... works" but also mention with what external dependencies (e.g. MSVCRT.DLL, like in this case). Kinda annoying to try it only to not have that file. (Sorry, I'm just paranoid about violating some obscure Windows license. Can you blame me?)

> CLOCK doesn't (strange, it used to crash on exactly same addr :confused:
> ), and the GPF's in Ring 0 persists :-(

There's already a DOS clock that looks and acts very very very similar (as well as yet another Win32 one written in VC++, which probably uses MSVCRT.DLL, go figure).

http://board.flatassembler.net/topic.php?p=61031#61031

Actually, that's only the FASM port of this. ;-)

---
Know your limits.h