1752717 Members
5577 Online
108789 Solutions
New Discussion юеВ

Re: analyze system dump

 
Bob Brason
Occasional Advisor

analyze system dump

Hi,
We have a system.dmp file from one of our customers that we need to analyze.This is on a tape we have tried to use the crash_dump command but we get this error link time of sys$base_image built into sda$share(19-nov-2004)does not match link time of image in system dump(10-aug-2005)unale to access location.
Any help is most appreciated
An optomist believes that we live in the best of all possible worlds, a pessist fears this to be true.
5 REPLIES 5
Volker Halle
Honored Contributor

Re: analyze system dump

Bob,

you need to analyse the system dump on the same version of OpenVMS, sometimes you might even need the same patch level.

I try to keep all versions of OpenVMS around or at least create environments, in which I can analyze older versions of OpenVMS.

10-AUG-2005 = VMS732_UPDATE-V0500 or -V0600
19-NOV-2004 = VMS V8.2 SSB

This won't work, you cannot expect to analyse a V7.3-2 dump on a V8.2 system - if my analysis is correct...

Is the dump valid, i.e. could the customer successfully do a ANAL/CRASH dumpfile, before he copied the dump to tape ?

Did you also request the CLUE file - was there a valid one in CLUE$COLLECT:CLUE$node_ddmmyy_hhmm.LIS ?

Volker.

PS: I do crashdump analysis as part of my job.
Hoff
Honored Contributor

Re: analyze system dump

As Volker writes, it's easiest to use the same version (and ECO) that generated the crash to analyze the crash.

You can sometimes get away with replicating the SDA environment files from the original version into the target environment, but that's a bit dicy. And unsupported. There are a handful of files needed if you try this, plus any symbol files related to what you're doing. And you'll have to aim SDA at the "right" files.

If you're debugging kernel code and can make changes, look around for details on the tr_print mechanism. (I've posted some at the web site.) It's a kernel-mode printf-like statement with output that goes into an easily-accessible ring buffer. Very useful when kernel things go off the rails.

Stephen Hoffman
HoffmanLabs LLC
Bob Brason
Occasional Advisor

Re: analyze system dump

Thanks to all we may need to approach this from a different angle
An optomist believes that we live in the best of all possible worlds, a pessist fears this to be true.
Jeff Chisholm
Valued Contributor

Re: analyze system dump

As you can imagine, we need to analyze crashes from each and every different version at the HP customer support center. We have an area set aside for each version and a symbol defined for invoking the right version of SDA with the right symbols tables, etc.

The %SDA-W-SDALINKISM errors don't generally matter if you can get to an SDA prompt.

Volker and Hoff are correct, but analyzing the dumpfile in situ, on the system where it happened, is probably the easist thing.

There's a per-event process in place so that customers without support contracts can get access to our experts using a PO or credit card for payment.
le plus ca change...
John Travell
Valued Contributor

Re: analyze system dump

I do not know if HP in the UK still has an effective CDA service. Things may well have changed since I left 5 years ago.
If you wish to consider an independent source of UK based expertise you are welcome to look up my profile and send me email.
Having said that, I concur with the previous replies, best choice where possible is to analyse on the machine that crashed. Where that is not possible the next best is to re-create the environment as closely as possible. As a last resort, and one that I have used a LOT, is an emulation of the CDA environment on a host machine running a later version.
JT: