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.