Hi ! strange bug found to-day, whereby the divide-error vector in V86_mode IDT at (physical) 0 is corrupted :

Incredibly, with soft ICE loaded it reads D8CA:F9E instead of 00CA:F9E ! (00CA being the MS-DOS.SYS segment on systems with 1 HD...) . Byte 3 corrupted !

I noticed that first on a Win95 and found the exact same bug on a quite different Win 98 SE !! Are you guys having same problem ? Or is it my copy only ?

Of course once acknowledged it is rather easily corrected - but this bizarre trashed byte @00000003 raises suspicion that other places in memory could be damaged too and stay unnoticed untill... boom ! ( As far as the RM IDT is concerned, only vector zero is damaged at byte 3)

Looking fwd to your evidence - could this be a 'well known' problem?

--
Cz.

O.T: since the W95 system is 486-based, I coded a tiny time-fixer for SICE. Just a .com that will read the time from the CMOS clock using int 1A and rewrite it to BIOS (and DOS) using int 21, took me five minutes to code under debug.exe (!) so hardly do I dare to offer it but if someone asks I'll post the 20 bytes or so. I do not have it available here and now, sorry...

Regards,

--
Czerno (The Passer-by)

Hi men !
My 'connectivity' has dropped to near zero
No comment of my previous msg ? Then I assume the problem is with my copy of SIce - True, I patched it a bit, but only the internal keyboard driver tables.

Here's what happens exactly : between when SIce is launched from real mode DOS 7 to when it breaks ( processing the INIT= string ), the byte at $0:3 is INCREMENTED by the constant 0D8h !!!!

If nothing is done at this stage, later when Win is loaded it will of course copy the trashed byte into the hidden copy of the RM memory it uses for initializing VMs ...

Workaround is to correct the byte 3 at this stage,
I added smthing like : eb $0:3 0 ... to my INIT string.
And it works, too

However I would like to investigate further what's happening ! Again , could you ppl quickly check whether or not your byte "3" is correct at SICe INIT time ?

My SICE version is 4.05 IIRC .

TYIA

--
Cz

Hi Czerno

My IVT shows the same thing with byte 3, and the msdos.sys segment seems to be 00C9 (only 1 HD) instead of your 00CA. Here's a partial output for my system, from a little app which spits out the vector table coded by [yAtEs] from his ID Intercepting DOS Interrupts and Vectors tut:


Vector Table Contents
-+-+-+-+-+-+-+-+-+-+-

Interrupt #00 D8C9:0F9E 0000:0000
Interrupt #01 0070:0465 0000:0004
Interrupt #02 0560:0016 0000:0008
Interrupt #03 0070:0465 0000:000C
Interrupt #04 0070:0465 0000:0010
Interrupt #05 F000:FF54 0000:0014
Interrupt #06 F000:7F58 0000:0018

No idea where the D8 comes from. Running Win98SE, SI 4.05(334). Do you think this has any effect on the system, or just that it shouldn't be happening in the first place?

Edit: Just tried without SI loaded (oh and what a naked feeling , and sure enough the correct entry is 00C9:0F9E. Any evidence from winice.exe where it's writing the D8 to the IVT?

Regards,
Kayaker

Thanks Kayaker 4 the feedback! I feel less lonely now

>Running Win98SE, SI 4.05(334).
Same here .

>Do you think this has any effect on the system, or just that it >shouldn't be happening in the first place?

Why of course it's a bug, you -must- have it corrected else any div by zero error in any app that doesn't have its own handler will crash the VM.

The workaround is simple however, as I mentionned in my previous post: only add an

"eb 3 0;"

to that INIT= string ...

Let's only hope that there are no other, less conspicuous but even more dangerous, glitches in our copies of that wonderful tool, S.Ice !

>Any evidence from winice.exe where it's writing the D8 to the IVT?

Not writing D8, rather ADDING it to whatever the inital byte at physical 00000003 !
One would want to debug the SIce initialization, but that is not easy, because debuggers do not like to be debugged Disassembling the winice.exe would seem to be an alternative,
if you feel like doing it. I haven't got time for such detours I am afraid.

Best wishes

--
Czerno