home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / os / vms / 19450 < prev    next >
Encoding:
Internet Message Format  |  1992-12-16  |  1.9 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!caen!spool.mu.edu!agate!dog.ee.lbl.gov!news!nosc!crash!cmkrnl!jeh
  2. From: jeh@cmkrnl.com
  3. Newsgroups: comp.os.vms
  4. Subject: Re: Looking for advice on tracking down a system crash
  5. Message-ID: <1992Dec16.134649.979@cmkrnl.com>
  6. Date: 16 Dec 92 13:46:49 PST
  7. References: <1gl3jvINN36s@dayub.dayton.saic.com>
  8. Organization: Kernel Mode Consulting, San Diego, CA
  9. Lines: 30
  10.  
  11. In article <1gl3jvINN36s@dayub.dayton.saic.com>, ake@dayton.saic.com (Earle Ake) writes:
  12. >     I have a system running VMS 5.4.  We have batch jobs that run one
  13. > process per job that control communications cards.  The software was recently
  14. > upgraded from VMS 4.7 to 5.4.  We have seen a few ramdom non-reproducible
  15. > system crashes recently.  Every system crash is due to the same executable.
  16. > Each bugcheck is a Machine check while in kernal mode.  
  17.  
  18. $ ANALYZE/CRASH dumpfilename
  19.  
  20. SDA> SHOW STACK
  21.  
  22. Interpreting the stack after a machine check is processor-dependent.  If you
  23. have access to VMS listings, check the file [V5n.SYSLOA.LIS]MCHECKxxx.LIS,
  24. where xxx is a code reflecting your processor type.   
  25.  
  26. Somewhere near the top of the stack will be a PC/PSL pair.  The PC is the
  27. address of the instruction that caused the problem.  
  28.  
  29. Machine checks associated with foreign device drivers are usually caused by
  30. the driver trying to touch a location that doesn't exist on the I/O bus.  I
  31. can't come up with a good reason offhand why this should be worse under
  32. 5.x than under 4.x.  I assume that you reassembled and relinked the drivers
  33. under 5.x?
  34.  
  35.     --- Jamie Hanrahan, Kernel Mode Consulting, San Diego CA
  36. drivers, internals, networks, applications, and training for VMS and Windows-NT
  37. uucp 'g' protocol guru and release coordinator, VMSnet (DECUS uucp) W.G., and 
  38. Chair, Programming and Internals Working Group, U.S. DECUS VMS Systems SIG 
  39. Internet:  jeh@cmkrnl.com, hanrahan@eisner.decus.org, or jeh@crash.cts.com
  40. Uucp:  ...{crash,eisner,uunet}!cmkrnl!jeh
  41.