said: 
>I'm writing directly to you, hoping you can help me! I'm having a couple= 
>of traps on my system as  follows: 
Please try to make these kinds of posts to SCOUG-Help first.  That way th= 
e 
information is there for other folks to see and it gets archived on the 
server.  If I'm slow to respond, then feel free to email me directly.  
It's unlikely that emailing me directly will get a faster response unless= 
the server is down. 
>	1.	Incharge traps, when Info-Zip saving Incharge files during closing o= 
f 
>Incharge 
>	2.	FileStar2 traps, when clicking on the "Directory" menu item 
What did you change recently? 
Are these process traps or kernel traps?  They look like process traps 
based on what you posted.  It is important that you state this clearly 
when reporting a trap. 
What tool did you use to extract the trap screens and where did you 
extract the trap screens from?  A process dump file or something else. 
I'll never figure out why you folks all seem to assume I can read your 
minds.  I must guess well enough, often enough to make you believe this i= 
s 
possible. :-) 
Are any of these trap screens for filestar?  You neglected to mark them 
clearly enough for me to guess correctly. 
>P1=3D00000002  P2=3D0fa00f1a  P3=3DXXXXXXXX  P4=3DXXXXXXXX   
>CS:EIP=3D005b:1c029d01  CSACC=3Df0df  CSLIM=3Dffffffff 
>SS:ESP=3D0053:013dffa8  SSACC=3Df0f3  SSLIM=3Dffffffff 
>EBP=3D013e00a8  FLG=3D00012202 
>EAX=3D013f0000  EBX=3D1c7a2c64  ECX=3D013effbc  EDX=3D0fa00f06 
>ESI=3D013ef844  EDI=3D013eff94   
>DS=3D0053  DSACC=3Df0f3  DSLIM=3Dffffffff   
>ES=3D0053  ESACC=3Df0f3  ESLIM=3Dffffffff   
>FS=3D150b  FSACC=3D00f3  FSLIM=3D00000030 
>GS=3D0000  GSACC=3D****  GSLIM=3D******** 
>c0000005 
>15f8182e 
>P1=3D00000002  P2=3D0fa00f1a  P3=3DXXXXXXXX  P4=3DXXXXXXXX   
>EAX=3D013f0000  EBX=3D1c7a2c64  ECX=3D013effbc  EDX=3D0fa00f06 
>ESI=3D013ef844  EDI=3D013eff94   
>DS=3D0053  DSACC=3Df0f3  DSLIM=3Dffffffff   
>ES=3D0053  ESACC=3Df0f3  ESLIM=3Dffffffff   
>FS=3D150b  FSACC=3D00f3  FSLIM=3D00000030 
>GS=3D0000  GSACC=3D****  GSLIM=3D******** 
>CS:EIP=3D005b:1c029d01  CSACC=3Df0df  CSLIM=3Dffffffff 
>SS:ESP=3D0053:013dffa8  SSACC=3Df0f3  SSLIM=3Dffffffff 
>EBP=3D013e00a8  FLG=3D00012202 
>c0000005 
>15f8182e 
>P1=3D00000002  P2=3D0fa00f1a  P3=3DXXXXXXXX  P4=3DXXXXXXXX   
>EAX=3D013f0000  EBX=3D1c7a2c64  ECX=3D013effbc  EDX=3D0fa00f06 
>ESI=3D013ef844  EDI=3D013eff94   
>DS=3D0053  DSACC=3Df0f3  DSLIM=3Dffffffff   
>ES=3D0053  ESACC=3Df0f3  ESLIM=3Dffffffff   
>FS=3D150b  FSACC=3D00f3  FSLIM=3D00000030 
>GS=3D0000  GSACC=3D****  GSLIM=3D******** 
>CS:EIP=3D005b:1c029d01  CSACC=3Df0df  CSLIM=3Dffffffff 
>SS:ESP=3D0053:013dffa8  SSACC=3Df0f3  SSLIM=3Dffffffff 
>EBP=3D013e00a8  FLG=3D00012202 
>C215MT.DLL 0001:0001182e 
>NOTE: C215MT.DLL is an Incharge DLL. 
Actually, it's the Borland C runtime.  Incharge is written in Borland C. 
Is there another version of this DLL anywhere else on your system? 
>	1.	What do I do with the CSLIM=3DXXXXXXXX values? Your article did not = 
say 
>anything  about that, 
You ignore it.  There are multiple trap screen images in the kernel.  Not= 
all will be filled in for every possible trap. 
>	2.	Next, for CS:EIP=3D005b:1c029d01 and  CSLIM=3Dffffffff, I used EIP=3D= 
005b 
>to look up the  (16 bit?) driver that seems to be causing the problem. I= 
t 
>says the following: 
Not quite. 53 and 5b are 32-bit selectors to process address space.  Note= 
the large eip value.  By definition a 16 bit driver will only have a 16 
bit offset (i.e. ffff max). 
The cs:eip value is pointing to the location in the named DLL where the 
trap occurred. 
>OK! I don't know what to do from here. I don't know what DOS$ means. 
DOS$ is the filename associated with the DOS.SYS driver, but as you 
probably realize by now, this has nothing to do with your problem. 
>Can 
>you help me here. 
The good news is all the traps you reported are at the same location.  
This implies you have a single problem somewhere. 
>C215MT.DLL 0001:0001182e 
This is a somewhat nasty trap location. 
Using my copy of: 
 4-26-96  14:58         210,356           0  C215MT.DLL 
lxlite shows that the trap is somewhere after: 
  00431      0:32      1:00011746, Exp 
which decodes to: 
  00431   _ExceptionHandler 
This means that Inchage caught an exception and died in the exception 
handler.  It really does not tell us as much as we would like to know. 
I'm guessing that both Incharge and Filestar are somehow tripping up over= 
something they have in common. 
What else have you done so far to try to track down the cause of the trap= 
s 
or to cure them? 
Do you have the Process Dump facility installed and correctly configured 
for your kernel? 
Do you have a process dump file for the Incharge trap? 
I'll wait for your reply before make further suggestions. 
Steven 
--  
---------------------------------------------------------------------- 
"Steven Levine"   MR2/ICE 2.47 #10183 Warp4/FP15/1= 
4.093c_W4 
www.scoug.com irc.fyrelizard.com #scoug (Wed 7pm PST) 
---------------------------------------------------------------------- 
===================================================== 
To unsubscribe from this list, send an email message 
to "steward@scoug.com". In the body of the message, 
put the command "unsubscribe scoug-help". 
For problems, contact the list owner at 
"rollin@scoug.com". 
===================================================== 
<< Previous Message << 
 >> Next Message >>
Return to [ 11 | 
October | 
2004 ]
The Southern California OS/2 User Group
P.O. Box 26904
Santa Ana, CA  92799-6904, USA
Copyright 2001 the Southern California OS/2 User Group.  ALL RIGHTS 
RESERVED. 
SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group.
OS/2, Workplace Shell, and IBM are registered trademarks of International 
Business Machines Corporation.
All other trademarks remain the property of their respective owners.