LO42892: SERVER KEPT CRASHING ON ADMINP AFTER THE SERVER UPGRADE

APAR status

• Closed as user error.

Error description

• One server kept crashing on adminp after applying a hotfix.
  
  - After the adminp task processed lots of requests, the server
  crashed on adminp.
  
  
  
  ############################################################
  ### FATAL THREAD 3/5 [ nAdminp:  1fe4:  1b50]
  ### FP=0x0ff8f2d0, PC=0x004632b6, SP=0x0ff8f1b4
  ### stkbase=0ff90000, total stksize=262144, used stksize=3660
  ### EAX=0x000006bb, EBX=0x00089f98, ECX=0x18fa0004,
  EDX=0x011835f0
  ### ESI=0x0da18c14, EDI=0x00000227, CS=0x0000001b,
  SS=0x00000023
  ### DS=0x00000023, ES=0x00000023, FS=0x0000003b, GS=0x00000000
  Flags=0x00010293
  Exception code: c0000005 (ACCESS_VIOLATION)
  ############################################################
  @[ 1] 0x004632b6 nAdminp.BatchRequest::PostProcessRequests+86
  (0,0,da18c14,d9)
  @[ 2] 0x00467894 nAdminp.BatchRequest::DoProcessRequest+676
  (3bca42,0,fdb2de8,ff8fd14)
  @[ 3] 0x00427272 nAdminp.AdminpProcessNewRequest@44+4434
  (d9,fdb2de8,15,2b3e,0,0,0,0,0,0,0)
  @[ 4] 0x0042aaa8 nAdminp.AdminpRequestAndResponse@40+1016
  (d9,fdb2de8,350236,2b56,0,0,0,0,0,0)
  @[ 5] 0x00402834 nAdminp.EntryThread@4+1140 (75d1e74)
  @[ 6] 0x6010494d nnotes.ThreadWrapper@4+173 (0)
   [ 7] 0x77e6482f kernel32.GetModuleHandleA+223 (601048a0)
  
  - There are many old requests (eg. Delete in Access Control
  List,
  Rename Group in Reader/Author fields, etc.) in admin4.nsf(set to
  purge
  documents of not modified in the last 21 days), which do not
  have a
  response document.
  
  
  
  - I did a testing that if setting "Store Admin Process log
  entries when
  status of no change is recorded" as "No" via Server document >
  Server
  Tasks > Administration Process > Miscellaneous, there is not a
  response
  document for the request when the request does not change
  anything.
  Normally, even though there is not a response document, this
  kind of
  requests will not be reprocessed.
  
  
  
  - However, from the console log, found these old requests were
  
  repeatedly reprocessed after the server started. It seems the
  adminp
  task re-scaned the whole admin4.nsf database. I suspect this may
  be
  caused by the server upgrade.
  
  
  
  - At the moment, after crashing at least 9 times, the server was
  running
  fine with the adminp task running. Maybe the adminp task had
  finished
  the scan of the whole admin4.nsf database.
  
  
  
  - There were another two server crashes when the administrator
  tried to quit the
  adminp task.
  
  
  
  ############################################################
  ### thread 8/9: [ nAdminp:  1ec4:  1ec8] FATAL THREAD (Panic)
  ### FP=327ad758, PC=7c82860c, SP=327ad6e8
  ### stkbase=327b0000, total stksize=262144, used stksize=10520
  ### EAX=0xc0000023, EBX=0x00000000, ECX=0x7c82e840,
  EDX=0x0000003d
  ### ESI=0x0000071c, EDI=0x00000000, CS=0x0000001b,
  SS=0x00000023
  ### DS=0x00000023, ES=0x00000023, FS=0x0000003b, GS=0x00000000
  Flags=0x00000293
  ############################################################
   [ 1] 0x7c82860c ntdll.KiFastSystemCallRet+0
  (71c,927c0,0,327adce0)
   [ 2] 0x77e61c8d kernel32.WaitForSingleObject+18
  (71c,927c0,3,327adefc)
  @[ 3] 0x601a8f24 nnotes.OSRunExternalScript@8+1300 (258,1)
  @[ 4] 0x601a93ba nnotes.FRTerminateWindowsResources+986
  (1,0,1010,1)
  @[ 5] 0x601a977f nnotes.OSFaultCleanupExt@24+895
  (bb4dd8,1010,0,0,0,327ae22c)
  @[ 6] 0x601a980a nnotes.OSFaultCleanup@12+26 (0,1010,0)
  @[ 7] 0x601b4d04 nnotes.OSNTUnhandledExceptionFilter@4+276
  (327af264)
  @[ 8] 0x60179dd8 nnotes.Panic@4+520 (60bc0b37)
  @[ 9] 0x60002b4c nnotes.LockHandle@12+252
  (fffe,327af294,327af2a0)
  @[10] 0x60008a16 nnotes.OSMemGetType@4+22 (60f00480)
  @[11] 0x600087ae nnotes.OSMemFree@4+30 (fffe)
  @[12] 0x00462f5f nAdminp.BatchRequest::DoQuitProcessing+63
  (19,0,327b0c14,122)
  @[13] 0x004678bb nAdminp.BatchRequest::DoProcessRequest+715
  (57b26,0,11c3b3c,327afd14)
  @[14] 0x00427272 nAdminp.AdminpProcessNewRequest@44+4434
  (122,11c3b3c,24,30bf,0,327afa74,f10f10,ffffffff,0,0,0)
  @[15] 0x0042aaa8 nAdminp.AdminpRequestAndResponse@40+1016
  (122,11c3b3c,2a25e,309a,0,327afd14,f10f10,ffffffff,0,0)
  @[16] 0x00402834 nAdminp.EntryThread@4+1140 (b77a798)
  @[17] 0x6010494d nnotes.ThreadWrapper@4+173 (0)
   [18] 0x77e6482f kernel32.GetModuleHandleA+223
  (601048a0,0,0,fffe0129)
  
  
  
  
  Error Message = PANIC: LookupHandle: handle out of range
  

Local fix

Problem summary

Problem conclusion

Temporary fix

Comments

• This APAR is associated with SPR# YYLN7UGCRM.
  The problem was caused by a user error.
  

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