Conference vaxaxp::vmsnotes

641.0. "PROCGONE bugcheck after installing an ECO" by MUCTEC::BECKER (Hartmut B., VMS & Languages, Munich) Mon May 26 1997 05:08

You may never see this problem but I want to mention it here in case anybody
else sees it. Maybe my quick analysis is wrong or incomplete but it fits to
what I saw. 

If your system disk is badly fragmented applying an ECO may leave your system
unbootable.

I installed ALPACRT02_071, made a shutdown with re-boot check and got a PROCGONE
bugcheck during the boot.

All my attempts to boot the system failed. The system crashed before I could
set the time (forced via sysboot settime set to 1). I booted from another disk
and checked what changed since the last successful boot. I removed or renamed
two UCX images which were in sys$loadable_images and which were replaced since
then. I disabled loading system images, I renamed all images mentioned in
VMS$SYSTEM_IMAGES.DATA, nothing helped. At last I renamed DECC$SHR.EXE which
was installed with that ECO. The system booted.

This surprised me because the same image was installed on a AS255, which was
successfully re-booted. I thought of dropping this ECO with the supplied
command procedure. A quick look into that COM-file showed it requires an old
version of DECC$SHR.EXE, hence I copied the old working one and re-booted:
The system crashed with PROCGONE at the same time during boot. This forced me
to have a closer look at that file, the file id, the header. I found that the
new DECC$SHR.EXE and the copied one had more than one header and more than 100
retrieval pointers. I concluded that at that stage during the boot such
fragmented files couldn't be mapped. I deleted some files and converted the new
DECC$SHR.EXE to a file with one header and only 30 retrival pointers: the
system booted without any complaint.

Maybe installation procedures can be made smarter to create less fragmented
new critical files. Maybe the re-boot check should check critical files for
fragmentation.

Hartmut

Crossposted to the DECC notes conference.

    These PROCGONE bugchecks will be triggered if a process which
    runs before the end of SYSINIT exits with an error. This includes
    SYSINIT. Normally the only information that is useful is the
    value in R0... so, if this ever happens to you again, set
    DUMPSTYLE so that you get full bugcheck output on the console.
    
    The status in R0 will give you the reason for the failure. Did the
    DECC$SHR image have more than one file header? The primitive file
    system can typically handle files that are very fragmented. It
    does not handle files with more than one header.
    
    Dave