Peter Knapper wrote to All on 11-28-1999

PK> Well I ran into something a little odd and was wondering if 
PK> anyone else has had the same happen to them. I have 2 
PK> machines, Machine A runing Warp 3 FP39, machine B running 
PK> Warp4 FP9. I have now discovered 2 pieces of S/W that will 
PK> run fine on machine B, but fail on machine A with a TRAP 5. 
PK> Here is the log from one of the failures -
PK> 
PK> =======================================================================
PK> 11-28-1999  16:00:57  SYS3175  PID 6a3a  TID 0001  Slot 0054
PK> C:\MAX\SQAFIXP.EXE c0000005 000000c0 P1=00000001  P2=000000c0 
PK> P3=XXXXXXXX  P4=XXXXXXXX   EAX=00000003  EBX=0000d75c  ECX=00000000 
PK> EDX=00000000 ESI=00000004  EDI=0000868e   DS=0037  DSACC=00f3 
PK> DSLIM=0000ce5f   ES=002f  ESACC=00f3  ESLIM=000010d6   FS=150b 
PK> FSACC=00f3  FSLIM=00000030 GS=0000  GSACC=****  GSLIM=********
PK> CS:EIP=005b:000000c0  CSACC=d0df  CSLIM=1fffffff
PK> SS:ESP=0037:0000cd10  SSACC=00f3  SSLIM=0000ce5f EBP=0000ce3a 
PK> FLG=00012246 

Peter, that error is sys3175 - illegal memory access (AKA GPF ). 
Since the programs in question are all DOS vdm's I'd suggest looking at
the DOS settings on both machines, especially the memory settings. 
Obvious question: these appear to be rather old programs so did they
ever work on the machine that's crashing??

One other thought:  try launching the one that crashes from a
full-screen DOS session.  If that works, you can be fairly certain that
the problem is due to extended memory usage.  One problem I've had is
inherent to the MSC5/6 - which is what this appears to be - and that is
a bug in the memory allocation  routine in the malloc function.  No
known cure for that except a re-compile with a fixed library but it
does produce out-of-bounds memory accesses.

Will Honea 
--- Maximus/2 2.02