Bugcheck 0000036c

[Wim Van den Wyngaert]

I compared all exe files with an identical systen. sys$base_images.exe was not the same. I copied it again to be sure. Still bugcheck.

Upgrade is not allowed. Nothing installed since 2003 !!

Wim

[Wim Van den Wyngaert]

Richard,

Show exec in ana/cra shows that all images were loaded (compared with a crash where the node exited the cluster after some uptime).

Wim

[Hoff]

[[[Upgrade is not allowed.]]]]

You've caught yourself very firmly in the enterprise trap, eh? Okfine. The more firmly a business gets itself stuck in that particular trap, the more it tends to cost the business. TANSTAAFL, as Mr Heinlein posited, applies here.

[[[ Nothing installed since 2003 !!]]]

Respectfully, um, so? Latent bugs have shown up after twenty or even thirty years, and all hardware eventually goes weird. There are PROCGONE bugcheck fixes around for V7.3 (I found one ECO listing a case where a directory appears to erroneously go walkabout), and for later releases.

Roll in your last good backup, or your post V7.3 install disk image. Or roll in a fresh installation of V7.3, and ECO to current. (That gets rid of all traces of Spiralog, too.)

Or pay somebody to get this bugcheck resolved within the site-local rules. The perceived savings and the safety of not upgrading -- the enterprise trap -- eventually do start to incur costs.

And check that battery. Those can and do fail, and an AlphaStation 400 (if that's what is in use here; I don't recall a 400 MHz variant) is certainly within the range for those failures; that box is easily old enough.

[Volker Halle]

Wim,

a successfull boot looks like this (from a V6.2-1H3 system with -fl 0,30000):

...
%SWAPPER-I-CREPRC, creating the SYSINIT process
%SWAPPER-I-MAINLOOP, entering SWAPPER main loop

%SYSINIT-I-START, SYSINIT process execution begins
%SYSINIT-I-UNLOAD, unloading EXEC_INIT
%SYSINIT-I-AUDIT, initializing security auditing
%SYSINIT-I-LOAD, loading RMS.EXE
%SYSINIT-I-LOAD, loading RECOVERY_UNIT_SERVICES.EXE
%SYSINIT-I-LOAD, loading DDIF$RMS_EXTENSION.EXE
%SYSINIT-I-LOAD, loading SYSMSG.EXE
%SYSINIT-I-ALTLOAD, loading site specific execlets
%SYSINIT-I-TIME, setting the system time
%SYSINIT-I-CLUSTER, cluster/lock manager initialization
%SYSINIT-I-DEFINE, defining system logical names
%SYSINIT-I-INIT, initializing the XQP
%SYSINIT-I-MOUNT, mounting the system disk
%SYSINIT-I-TIME, setting the system time
%SYSINIT-I-FILCACHE, deallocating the primitive file cache
%SYSINIT-I-DEFINE, defining SYS$TOPSYS
%SYSINIT-I-OPEN, marking system files open
%SYSINIT-I-CREPRC, creating the STARTUP process
%SYSINIT-I-FINISH, SYSINIT process execution completed
...

In your PROCGONE crash R0=00000910 = %SYSTEM-W-NOSUCHFILE must indicate, that SYSINIT failed to start. Look for all images required for SYSINIT.EXE to start and see if they all exist and can be successfully accessed:

From $ ANAL/IMA SYSINIT.EXE
...
Shareable Image List

0) "DECC$SHR"
1) "LIBRTL"
2) "LIBOTS"
3) "SYS$BASE_IMAGE"
4) "SYS$PUBLIC_VECTORS"

Volker.

[Volker Halle]

Wim,

the current process name is SYSINIT and there is no image name. This may the symptom of an image activation problem !

Look at the Image Activator Scratch Area in the dump.

SDA> clue proc/lay
...
Image Activator Scratch Area 00000000.xxxxxxxxx 00000000.7FFD1800 00001000
...

SDA> exa xxxxxxxx;1000

do you see a filename in the ASCII dump ?
Does that file exist ?

Volker.

[Wim Van den Wyngaert]

In the mean time the disk has been replaced.
I still have the old disk but can't play with it in boots. A backup copy to the new disk gave no errors during backup but during the verification of the backup (/ver) about 20 parity errors were given. None of them on exe files (mostly cde files). The boot of the copy resulted in the same crash. We recreated the OS on the new disk from scratch.

Volker,

The address exa shows multiple file names.
See enclosure. All exe files you mentioned existed.

Wim

[Volker Halle · Accepted solution]

Wim,

any shareable images missing, which the shareable images directly linked to SYSINIT may need ?

Volker.

[Wim Van den Wyngaert]

Missing are : CMA$* (4), CRFSHR.

Last week I compared all files present with those on another system and discovered 1 file different. I should have compared all exe files.

Are these files the reason ? I found cms$tis_shr in the sda enclosure too.

Wim

[Richard Brodie_1]

cms$tis_shr is one of the shared images that decc$rtl depends on, so it would be indirectly needed for SYSINIT (at least if the normal image activation rules apply).

[Volker Halle]

Wim,

I just learned that there is a toolset called VOIT on the V8 freeware CDs. It contains the tool SHMTL, which diagnoses and prints the shareable image list for a given image and it's dependant shareable images. Much easier than multiple invocations of ANAL/IMAGE...

Volker.