Conference noted::pwv50ift

4146.0. "pw5.0d pwrk$upgrade access violation" by VMSNET::D_THAXTON () Tue Feb 04 1997 22:51

Below is what I suggested the customer do for the following problem.
Has anyone else seen this type of access violation when running
the pwrk$upgrade. PW 5.0D e03.

Find out which share directory structure it       |
blew up on and then edit:                                                 |
|
pwrk$lmroot:[lanman.datafiles]pwrk$upg$share.dat                          |
|                                                                              |
|    and remove the sharenames (starting from top of file) that it has         |
|    successfully upgraded security for.  That is, the share it blew up on     |
|    should be at the top of the file when you're done editing.                |
|                                                                              |
|    Then simply re-run PWRK$UPGRADE and start the security upgrade again.     |
|    It should pick up on the share it blew up on.  I think you'll find it     |
|    gets through this share this time; if not, remove that sharename from     |
|    the file and start again.  Then when you're done, start the v5 server     |
|    and manually apply permissions to the directories in the share the        |
|    upgrade failed to set permissions on.


 Find out which share directory structure it blew up on and then edit:     |

|I think you'll find the share name in the upgrade log file.  I think it will  |
|list the shares its processing and the one you want is the last one it says   |
|its processing.

Thanks for using DSNlink
Dave,

As we spoke on Monday Febuary 3, 1997, we explained that we were also
experiencing ACCVIO's when tring to set the security for the permissions on
LANMAN shares using PWRK$UPGRADE.  We are using the CUSTOM upgrade option and
doing the security upgrade disk by disk.  We have increased the FILLM ten
fold,
WSQUO tripled, and WSEXTENT tripled on the SYSTEM account as you suggested,
but
we are still ACCVIO'ing.

Below is the contents of the dump.

Please advise,

Derek Wilford
The Lubrizol Corp
(216) 943-1200 x5953
[email protected]

%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=2E2E2E36,
PC
=000DFDC8, PS=0000001B
%TRACE-F-TRACEBACK, symbolic stack dump follows
 Image Name   Module Name     Routine Name    Line Number  rel PC      abs PC
 PWRK$UPGRADE DB_ACCESS       DBget                 11747 00001898    000DFDC8
 PWRK$UPGRADE USERMODE        Group_nameget         39890 00005DF8    000B9318
 PWRK$UPGRADE USERMODE        Group_id              39977 00005FD8    000B94F8
 PWRK$UPGRADE UPG_PHASE3      add_acl               38963 00001AA8    00058FF8
 PWRK$UPGRADE DIRECTORY       util_do_lm_prot       34763 00000838    0006CBD8
                                                        0 8043BCAC    8043BCAC
                                                        0 80455ECC    80455ECC
 PWRK$UPGRADE DIRECTORY       util_walk_dir_t       34602 00000248    0006C5E8
 PWRK$UPGRADE UPG_PHASE3      cvt_service_rms       38622 00000FCC    0005851C
 PWRK$UPGRADE UPG_PHASE3      upg_phase3            38307 00000630    00057B80
 PWRK$UPGRADE SMGMAIN         process_advance       31945 0000165C    000517FC
 PWRK$UPGRADE SMGMAIN         process_main_me       31640 00001078    00051218
 PWRK$UPGRADE SMGMAIN         fsp1$main             31099 00000360    00050500
 PWRK$CSSHR_V MTS             MTS$MAIN_SCHEDU        6694 00000104    0023B184
 PWRK$UPGRADE MTS$MAIN        main                   4322 000000BC    000500BC
 PWRK$UPGRADE MTS$MAIN        __main                    0 00000058    00050058
                                                        0 8A8C0170    8A8C0170

    Dave,
    
    I can't find any history on this particular footprint either.  It could
    be a resource issue (ie, channelcnt, enqlm) or it could be a corrupt
    accounts.lmx database (you might see if lmgroup -l and lmuser -l
    commands work w/o error). 

Actually, we have seen a case with a similar footprint.  ACCVIOing when trying
to add ACLs.  The workaround you provided the customer is correct.

Brad

    Thanks, all for the input. The ACL's looked like the problem.
    
    Dave