LO79842: CRASH ON DAOS MANAGER WHEN MOVING TO NEW OS

APAR status

• Closed as fixed if next.

Error description

• The customer migrated two cluster servers running Lotus Domino
  8.5.3FP6 32-bit from Windows 2003 32-bit to Windows 2008 R2
  64-bit running Lotus Domino 8.5.3 FP6 64-bit.
  After that the following errors appeared DAOS:
  The DAOS catalog cannot be updated.: Document attachment is
  invalid
  The solution to this was to run the following commands
  Tell DAOSMgr Resync
  .
  Tell DAOSMgr Resync -quick
  .
  Tell DAOSMgr Resync -force
  This resulted in a crash
  ###########################################################
  ### thread 4/8: [nDAOSMgr: 124c: 1284] FATAL THREAD
  ### FP=0x164c2988, PC=0x77bd12fa, SP=0x164c2988
  ### stkbase=0x164d0000, total stksize=4194304, used
  stksize=54904
  ### EAX=0x00000041, EBX=0x00000000, ECX=0x164c1962,
  EDX=0x7FEE74D1D37
  ### ESI=0x000493e0, EDI=0x000009d8, CS=0x00000033,
  SS=0x7FE0000002B
  ### DS=0x00000000, ES=0x00000000, FS=0x00000000,
  GS=0x7FE00000000
  Flags=0x00000287
  ############################################################
   [ 1] 0x77bd12fa ntdll.ZwWaitForSingleObject+10
  (448C6658E2B7,122a5229,3,13d29980)
   [ 2] 0x7FEFDC210DC KERNELBASE.WaitForSingleObjectEx+156
  (5,5,0,9d8)
  @[ 3] 0x10096a1b nnotes.FRSendCommandToService+1943
  (164c8000,164c8318,0,10092d04)
  @[ 4] 0x1009a304 nnotes.OSRunExternalScript+5860
  (3,5,1231c4a4,1)
  @[ 5] 0x10093b31 nnotes.FRTerminateWindowsResources+2277
  (80,80,0,204880)
  @[ 6] 0x1009d2ce nnotes.OSFaultCleanupExt+622
  (0,10092ecb,150014,123205b0)
  @[ 7] 0x1009dd45 nnotes.OSFaultCleanup+29 (0,50,0,164ca0ac)
  @[ 8] 0x100b78be nnotes.OSNTUnhandledExceptionFilter+626
  (164cab70,0,1,0)
   [ 9] 0x779f9460 kernel32.UnhandledExceptionFilter+352
  (164cab70,6,0,1)
   [10] 0x77c13398 ntdll.MD5Final+7656
  (FF00000000,FF000001FE,1000000FF,0)
   [11] 0x77b985c8 ntdll.__C_specific_handler+156
  (164d0000,164cff90,164cff90,77cc2dd0)
   [12] 0x77ba9d2d ntdll.RtlDecodePointer+173
  (164d0000,77a6df08,12f00,164cb074)
   [13] 0x77b991cf ntdll.RtlUnwindEx+3007
  (164cb7b0,164cb2c0,4C005C00000000,73007500000000)
   [14] 0x77bd1248 ntdll.KiUserExceptionDispatcher+46
  (100bb658,0,164cc590,0)
  @[15] 0x1119ddf1 nnotes.Cstrncpy+13 (0,164cc590,0,20001fe)
  @[16] 0x100bb658 nnotes.OSPathWalkGuts+704
  (3fc5f980,100574a8,1,1)
  @[17] 0x10064f4b nnotes.OSPathWalk+939
  (164cdab0,35800000012,0,100000000)
  @[18] 0x10066406 nnotes.OSFileExistCheck+922
  (3fc5f4d4,164cd860,354,164cd870)
  @[19] 0x115abd59 nnotes.IDTableRecycle+385
  (C4000000B1,8549678,0,11b69df3)
  @[20] 0x116c847e nnotes.EHScanLeaf+774 (C4000000B1,a809,0,b5)
  @[21] 0x116c7f94 nnotes.EHScan+2080 (164ce360,124608b0,f1,0)
  @[22] 0x115ac561 nnotes.NSFDAOSIDTableRebuild+1609
  (3240b0,1297c17c,1245c86c,100)
  @[23] 0x1159d6f8 nnotes.DAOSIDTableRebuild+80
  (1245c804,1245c88c,0,378688)
  @[24] 0x115a0ede nnotes.DAOSRebuildCatalog+1678
  (0,1245e84c,1,1)
  @[25] 0x1159f6f7 nnotes.DAOSResyncCatalog+511
  (0,41b960,0,3323)
  @[26] 0x00405229 nDAOSMgr.ResyncThread+673 (0,0,0,0)
  @[27]
  The crash happens during a scan of the old daoscat.nsf while
  meets an invalid entry. Domino does not ODS the data in
  daoscat.nsf. The problem is not fixed and thus will also occur
  between migrations from  32 and 64 bit OS's.
  

Local fix

• In order to fix the problem, the DAOS catalog needs to be
  deleted (renamed) and re-created (and that will lose their
  deletion list history in the process) as below.  The NLO and
  NSF files themselves should be fine, it's just the daoscat that
  has a problem.
  1) shut down Domino and all Domino-related processes
  2) rename daoscat.nsf to daoscat.nsf.old
  3) run 'daosmgr resync quick' standalone from the command line
  4) start Domino
  5) run 'daosmgr resync' at a convenient time to complete the
  refcount portion of the resync operation.  (alternatively, this
  can be done at step 3 by leaving off the 'quick' keyword)
  

Problem summary

• This APAR is closed as FIN. We have deferred the fix to a
   future release.
  

Problem conclusion

Temporary fix

Comments

• This APAR is associated with SPR# GTON9HTFBQ.
  This APAR is closed as FIN. We have deferred the fix to a
   future release.
  

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

Fix information

Applicable component levels

• R901 PSN

     UP