LotusScript call to NSFItemInfoNext on Domino 64 bit server crashes server

1

I'm trying to make a call from a LotusScript agent to 'NSFItemInfoNext' on a Domino 9.0.1 64-bit server. The call to 'NSFItemInfo' succeeds. The code has been tested on a 32-bit and works correctly. The field is a rich text field broken into several items.

    Type BLOCKID64
        Pool As Long
        Block As Integer
    End Type

    Declare Function W64_NSFItemInfo Lib LIB_W32 Alias "NSFItemInfo" (ByVal noteHandle As Long, ByVal itemName As String, ByVal nameLength As Integer, itemBlockID As BLOCKID64, valueDataType As Integer, valueBlockID As BLOCKID64, valueLength As Long) As Integer

    Declare Function W64_NSFItemInfoNext Lib LIB_W32 Alias "NSFItemInfoNext" (ByVal noteHandle As Long, ByVal prevItemBlockIDPool As Long, ByVal prevItemBlockIDBlock As Integer, ByVal itemName As String, ByVal nameLength As Integer, itemBlockID As BLOCKID64, valueDatatype As Integer, valueBlockID As BLOCKID64, valueLength As Long) As Integer

    Dim dbHandle As Long
    Dim noteHandle As Long
    Dim RTItemName As String
    Dim ItemBlockID As BLOCKID64
    Dim ItemDataType As Integer
    Dim ValueBlockID As BLOCKID64
    Dim ValueLength As Long
    Dim NextItemBlockID As BLOCKID64
    Dim NextItemDataType As Integer
    Dim NextValueBlockID As BLOCKID64
    Dim NextValueLength As Long
    Dim StatusResult As Integer

    RTItemName = "Body"

    NSFDbOpen - dbHandle: 377
    NSFNoteOpen - noteHandle: 43

    StatusResult = W64_NSFItemInfo(noteHandle, RTItemName, Len(RTItemName), ItemBlockID, ItemDataType, ValueBlockID, ValueLength)

    Results of call to NSFItemInfo:
    itemBlockID.Pool: 43
    itemBlockID.Block: 31312
    itemDataType: 1
    valueBlockID.Pool: 43
    valueBlockID.Block: 1120
    valueLength: 30176

    StatusResult = W64_NSFItemInfoNext(noteHandle, ItemBlockID.Pool, ItemBlockID.Block, RTItemName, Len(RTItemName), NextItemBlockID, NextItemDataType, NextItemValueBlockID, NextItemValueLength)

    Call to NSFItemInfoNext fails with the following crash:

    ############################################################
    ### thread 10/11: [   nAMgr:  1ca4:  0c60] FATAL THREAD
    ### FP=0x185ba4c8, PC=0x7723695a, SP=0x185ba4c8
    ### stkbase=0x185c0000, total stksize=1048576, used stksize=23352
    ### EAX=0x0000db76, EBX=0x00000538, ECX=0x185b9518, EDX=0xFFFFFFFF01E6AF0
    ### ESI=0x00000000, EDI=0x00000000, CS=0x00000033, SS=0xFFFFFFF0000002B
    ### DS=0x00000000, ES=0x00000000, FS=0x00000000, GS=0xFFFFFFF00000000 Flags=0x00000287
    ############################################################
     [ 1] 0x7723695a ntdll.ZwWaitForSingleObject+10 (0,0,0,0)
     [ 2] 0x76d6aeb0 kernel32.WaitForSingleObjectEx+160 (538,185babb0,0,538)
    @[ 3] 0x7FEE2846AA2 nnotes.OSRunExternalScript+1666 (1ca4,0,426,5)
    @[ 4] 0x7FEE28472EA nnotes.FRTerminateWindowsResources+1738 (0,5,1,2b9190)
    @[ 5] 0x7FEE2847A79 nnotes.OSFaultCleanupExt+1177 (185bbe60,772f9d40,185bf9d0,1)
    @[ 6] 0x7FEE2848077 nnotes.OSFaultCleanup+23 (772f9d40,2a2,29,185bb3e0)
    @[ 7] 0x7FEE28AA997 nnotes.OSNTUnhandledExceptionFilter+423         (185bbe60,772f9d40,30,185bbe60)
     [ 8] 0x76dfcbef kernel32.UnhandledExceptionFilter+351 (185bbe60,4a04f3ca,0,1)
     [ 9] 0x77261348 ntdll.RtlInitializeAtomPackage+72 (7FEE4623CB0,13000000016,200005445,29)
     [10] 0x77228ec4 ntdll.__C_specific_handler+140 (185bf9d0,185bf9d0,185c0000,77216411)
     [11] 0x7722546d ntdll.RtlIntegerToChar+1341 (1,0,185bf9d0,185c0000)
     [12] 0x77229267 ntdll.__C_specific_handler+1071 (185bca40,2598ca4,0,771f0000)
     [13] 0x7723687a ntdll.KiUserExceptionDispatcher+46 (2598ca4,2b,185bcb88,188fc110)
    @[14] 0x7FEE350B7C4 nnotes.NSFItemInfoNext+100 (185bcd20,2b,188fc7a0,188fc110)
    @[15] 0x7FEE3B29803 nnotes.LSsThread::DoCCallout+6355 (ffff,188fc758,0,2598ca4)
    @[16] 0x7FEE3B2B3FF nnotes.LSsThread::CProdCallFunction+431 (2598ca4,185bd7c8,23,ffe8)
    @[17] 0x7FEE3AED292 nnotes.LSsThread::NRun+8722 (188fc110,185b08a4,3,2)
    @[18] 0x7FEE3AEDAD8 nnotes.LSsThread::Run+296 (188fc110,76b9028,0,2)
    @[19] 0x7FEE3AA7C3A nnotes.LSIThread::RunInternal+106 (76b9028,76b9028,0,0)
    @[20] 0x7FEE3AA7EF6 nnotes.LSIThread::RunToCompletion+390 (76a8b28,76a8b28,185bdb30,0)
    @[21] 0x7FEE3AA0CAA nnotes.CLSIDocument::RunScript+762 (76aa828,76a8aa8,0,76a8aa8)
    @[22] 0x7FEE2F1B8EC nnotes.CRawActionLotusScript::Run+668         (20000200,7FE00000026,C2520646E756F46,56D756300000026)
    @[23] 0x7FEE2F16E5F nnotes.CRawAction::Run+95 (0,76a8a68,76aa828,7FEE28F0005)
    @[24] 0x7FEE2F17B44 nnotes.CRawAction::Execute+260 (ff,0,0,8f9b)
    @[25] 0x7FEE2F1497E nnotes.CAssistant::Run+4174 (200002bf,185bea40,76a8b28,0)
    @[26] 0x7FEE2F32B9F nnotes.AgentRun+1711 (1,0,0,10)
    @[27] 0x7FEF99F8420 namgrdll.ExecConsoleAgent+320 (80,adc92,76aa828,76aa028)
    @[28] 0x7FEE2858B52 nnotes.ThreadWrapper+258 (0,0,0,0)
     [29] 0x76d5aefd kernel32.BaseThreadInitThunk+13 (0,0,0,0)
     [30] 0x77216411 ntdll.RtlUserThreadStart+33 (0,0,0,0)

I've tried changing 'Pool' in BLOCKID64 structure to Double but that didn't work and caused the value returned to 'Block' to be 0 (zero).

Any thoughts or suggestions? Has anyone else had issues with 64-bit API calls from LotusScript.

64-bit
lotus-domino
lotus
asked on Stack Overflow Mar 24, 2014 by user3453536 • edited Mar 24, 2014 by Prasad Jadhav

1 Answer

1

I would suggest to change ItemBlockID to Double instead of using a structure. You do not use this structure anyway (for anything else than passing in the next call).

Declare Function W64_NSFItemInfo Lib LIB_W32 Alias "NSFItemInfo" (ByVal noteHandle As Long, ByVal itemName As String, ByVal nameLength As Integer, itemBlockID As Double, valueDataType As Integer, valueBlockID As BLOCKID64, valueLength As Long) As Integer

Declare Function W64_NSFItemInfoNext Lib LIB_W32 Alias "NSFItemInfoNext" (ByVal noteHandle As Long, ByVal prevItemBlockIDDbl As  As Double, ByVal itemName As String, ByVal nameLength As Integer, itemBlockID As BLOCKID64, valueDatatype As Integer, valueBlockID As BLOCKID64, valueLength As Long) As Integer

About the question if anybody got problems using with 64-bit API calls from LotusScript - I'd be surprised if anybody has managed to "go all the way". For example once you get the items, you might want to read the content... I'm still stuck on that one :-/ I thought I have figured it out... but where is that code :-)


User contributions licensed under CC BY-SA 3.0