said:
>What does a SYSLOGPM "Exception type: c0000005"
>mean? An 0005 is a Bounds Check . . .
No, it doesn't. Open up your copy of the OS/2 Debugging Handbook and
search for:
exception code
You are confusing exception codes with Intel trap codes. They are not the
same.
To save you the stress of locating and, perhaps, installing the Handbook:
0C0000005H
XCPT_ACCESS_VIOLATION
This relates to Traps 0x09, 0x0b, 0x0c, 0x0d and 0x0e.
P1 Access Code
00000000H XCPT_UNKNOWN_ACCESS
00000001H XCPT_READ_ACCESS
00000002H XCPT_WRITE_ACCESS
00000004H XCPT_EXECUTE_ACCESS
00000008H XCPT_SPACE_ACCESS
00000010H XCPT_LIMIT_ACCESS
P2
FaultAddr
XCPT_READ_ACCESS/XCPT_WRITE_ACCESS
Selector XCPT_SPACE_ACCESS
-1
XCPT_LIMIT_ACCESS/XCPT_UNKNOWN_ACCESS
>I must have a lot of hardware glitches! The two workstations on my desk
>both "glitch" regularly, though I think one of them is a video driver
They are tough to isolate. What I do is maintain a boot log. This is
pretty much automated. A command in startup.cmd writes a timestamp record
to the log file and an object in the startup folder opens the log file in
EPM and positions it to the last line. All I have to do is note what I
was doing that required the reboot. After a while, any non-obvious
patterns will reveal themselves.
>problem (Elsa) and my note to install SciTech is slowly moving up my
>"Install These" list. Don't know if a video driver can cause a c0000005
>in PMWP.DLL.
Now that you know what c0000005 means, it should be clear that any piece
of code can.
>clean INI's, most of my glitches happen during XCOPY or XCOMP (Roman
>Stangl's XCOPYesque COMP). These are command line but I still think the
>Elsa driver has something to do with the "glitches" . . .
Perhaps. Are these local or network copy's? I would suspect disk
controller or NIC respectively.
>quick look at SYSLOGPM.HLP shows that when the log file "wraps" the files
>are deleted. Cool -- otherwise I'd have about a gigabyte tied up with
Yep. IBM knows how to do this stuff. What amuses me is the number of
folks that recommend turning off and/or disabling all the failure analysis
tools. Seems to me, it would be better to spend a little time to
understand what's there and make use of it. But, that's just me.
>directory; maybe I'll just manually delete them since the log file
>wrapped over their entries a long time ago.
I would. It just indicates that the log itself got corrupted somewhere
along the way. It's similar to what happens with the Netscape cache, from
time to time.
Steven
--
---------------------------------------------------------------------
"Steven Levine" MR2/ICE 2.31a #10183 Warp4/FP15/14.085_W4
www.scoug.com irc.webbnet.org #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 [ 16 |
May |
2002 ]
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.