home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / os / vms / 19552 < prev    next >
Encoding:
Internet Message Format  |  1992-12-21  |  2.1 KB
  1. Path: sparky!uunet!spool.mu.edu!agate!ucbvax!lrw.com!leichter
  2. From: leichter@lrw.com (Jerry Leichter)
  3. Newsgroups: comp.os.vms
  4. Subject: re: Looking for advice on tracking down a system crash
  5. Message-ID: <9212181327.AA17581@uu3.psi.com>
  6. Date: 18 Dec 92 11:58:11 GMT
  7. Sender: daemon@ucbvax.BERKELEY.EDU
  8. Distribution: world
  9. Organization: The Internet
  10. Lines: 39
  11.  
  12.  
  13.     I have a system running VMS 5.4.  We have batch jobs that run one
  14.     process per job that control communications cards.  The software was
  15.     recently upgraded from VMS 4.7 to 5.4.  We have seen a few ramdom
  16.     non-reproducible system crashes recently.  Every system crash is due
  17.     to the same executable.  Each bugcheck is a Machine check while in
  18.     kernal mode.  I am looking for advice on how to track this down.  I
  19.     have saved the system dump files but not knowing how to read them puts
  20.     me at a disadvantage.  I have suggested adding a set process/dump
  21.     before the executable is run so that is in place now but we have not
  22.     had a crash yet.
  23.  
  24.     Using debug is out of the question since the device the executable
  25.     controls is realtime.  Would compiling with debug but not linking with
  26.     debug also help?  I am looking for any help I can get since I am
  27.     experienced at debugging but not real-time devices or those that cause
  28.     system crashes!
  29.  
  30. SET PROCESS/DUMP, DEBUG, and such will not help; a machine check will yank the
  31. machine out from under them.  However, even if it didn't, they are beside the
  32. point:  They are user-mode debugging utilities, and we are talking about a
  33. kernel-mode problem.
  34.  
  35. A machine check usually means just that:  A hardware problem.  Given the
  36. symptom of a machine check, my guess as to the cause is:
  37.  
  38.     99%    Hardware flakey.
  39.     <1%    Privileged code problem "faking" a machine check.
  40.     <1%    VMS bug.
  41.  
  42. Those "<1%" are actually MUCH less than 1% - in fact, I've never seen this
  43. happen.  While bugs in privileged code and in VMS certainly cause crashes,
  44. it takes some doing to simluate a machine check.
  45.  
  46. Have you checked the systems error logs?  A real-time process is presumably
  47. making heavy use of one or more I/O devices - look particularly at the state
  48. of health of those devices.
  49.                             -- Jerry
  50.  
  51.