在 Domino 64 位服务器上对 NSFItemInfoNext 的 LotusScript 调用使服务器崩溃

Question

我正在尝试从 LotusScript 代理调用 Domino 9.0.1 64 位服务器上的“NSFItemInfoNext”。对“NSFItemInfo”的调用成功。该代码已在 32 位上进行了测试，并且可以正常工作。该字段是一个富文本字段，分为多个项目。

    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)

我尝试将 BLOCKID64 结构中的“Pool”更改为 Double，但没有成功，导致返回“Block”的值为 0（零）。

有什么想法或建议吗？有没有其他人遇到过来自 LotusScript 的 64 位 API 调用的问题。

Answer 1

我建议将 ItemBlockID 更改为 Double 而不是使用结构。无论如何，您都不会使用此结构（除了传递下一个调用之外的任何其他内容）。

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

关于是否有人在使用来自 LotusScript 的 64 位 API 调用时遇到问题的问题 - 如果有人设法“一路走来”，我会感到惊讶。例如，一旦你拿到了这些项目，你可能想阅读内容......我仍然坚持那个：-/我以为我已经弄清楚了......但是那个代码在哪里:-)