customer DLL; run-time error 53

[S.Br.]

Dear Mr.Excel;
I have the following fragment in my Add-in (written with VBA7.1):

Option Explicit
Public Declare PtrSafe Sub mysubTst Lib "mylibTst.dll" ()
Public Sub Tst()
  mysubTst
End Sub

it behaves as expected under Windows ver.10.0.19045 with XL 2307(16626.20134)
but fails with RTErr 53 under Windows ver.10.0.22621 with XL 2307(16626.20170).
The Error message (File not found) pops-up regardless of where I put the DLL file:
I've tried several folders: C:\WINDOWS\SYSTEM32; Excel.exe location; Add-Ins folder,
(the DLL is compiled with MSVS2022; all dependents are present in C:\WINDOWS\SYSTEM32).
What else should I try? Any advice is strongly appreciated. TIA =S.Br.=

 

[Dan_W]

Try specifying the exact path of the DLL file in the API Declaration. For example:

Public Declare PtrSafe Sub mysubTst Lib "C:\PathOfFile\mylibTst.dll" ()

And see if that works.

Just to clarify, are you calling the DLL from the correct bitness office? If the DLL is 32-bit, for example, you can't call it from 64-bit Office (and vice-versa). It isn't immediately obvious to me from your info above which version of Office you're using: 32-bit or 64-bit. This could explain why it works on one system and not the other.

 

[S.Br.]

Thanks for your time, Dan;
Using the full path to DLL gives that same error; the bitness is correct (64bit DLL for 64bit XL on 64bit windows).
Wrote a lil 64bit test app (all it does just loads mylibTst.DLL) - everything is fine, all exported functions are ok.
Have you heard of new s.c. safety features for recent XLs where customers are not allowed to run non-ms code?
I have a feeling there's some kind of new security option added by ms to the latest xl version. Regards, SBr.

 

[Dan_W]

Hmm - odd. I'm aware of the safety features put in place re: workbooks with macros and (I'm assuming you're referring to) XLLs, but those are just simple measures for people who aren't familiar with code enabled workbooks. Both XLSM and XLL files can be "Unblocked" and then used easily enough - Microsoft set out the process on their site. But in any event, those don't apply to DLL files.

Writing a 64bit Test app isn't going to be particularly helpful here (save that it evidences bitness...) given that the error message is specifically saying it can't find the DLL.
I've recently written test DLLs in TwinBasic for both 32bit and 64bit Office, and it worked fine.

What's particularly odd is how it works in one version but not the other...

 

[S.Br.]

Hmm - odd. I'm aware of the safety features put in place re: workbooks with macros and (I'm assuming you're referring to) XLLs, but those are just simple measures for people who aren't familiar with code enabled workbooks. Both XLSM and XLL files can be "Unblocked" and then used easily enough - Microsoft set out the process on their site. But in any event, those don't apply to DLL files.

Writing a 64bit Test app isn't going to be particularly helpful here (save that it evidences bitness...) given that the error message is specifically saying it can't find the DLL.
I've recently written test DLLs in TwinBasic for both 32bit and 64bit Office, and it worked fine.

What's particularly odd is how it works in one version but not the other...

Accidentally I found a solution:
but... first of all I have to correct my original post: the file name I used in my OP "mylibTst.DLL" is not the real one; the actual file name is not in 8.3 format; it has more that 8 chars in its name.
Solution: I renamed my DLL in "C:\WINDOWS\SYSTEM32" folder to have no more than 8 characters (+".DLL"). I wish someone could explain it to me. Thanks for your help. Regards. =S.Br.=

 

[S.Br.]

Accidentally I found a solution:
but... first of all I have to correct my original post: the file name I used in my OP "mylibTst.DLL" is not the real one; the actual file name is not in 8.3 format; it has more that 8 chars in its name.
Solution: I renamed my DLL in "C:\WINDOWS\SYSTEM32" folder to have no more than 8 characters (+".DLL"). I wish someone could explain it to me. Thanks for your help. Regards. =S.Br.=

it is not a solution, it's a work-around until I understand why it works. What do you think, Mr. Excel?

 

[Dan_W]

Just for completeness, I thought I would share this code that I wrote some time ago to determine the bitness of DLL/OCX/TLB/EXE files. There may well be a better/quicker way of writing it, but I thought I would share it here in case of help to you/someone wanting to confirm the bitness of the file that they're dealing with (I know it doesn't apply exactly to your situation above, but still):

    Option Explicit
    
    Public Enum FILE_BITNESS_ENUM
        BITNESS_UNKNOWN
        x86_32BIT
        x64_64BIT
    End Enum
    
    Public Sub TestFileBitness()
        
        Dim BitnessType() As String, Result As FILE_BITNESS_ENUM, FileName As String
        BitnessType = Split("Unknown|32-bit|64-bit", "|")
        FileName = "D:\PathToDLL\DLLFilename.DLL"
        Result = GetFileBitness(FileName)
        MsgBox BitnessType(Result)
        
    End Sub
    
    Public Function GetFileBitness(ByVal FilePath As String) As FILE_BITNESS_ENUM
        
        On Error GoTo ErrHandler
        Dim Offset      As Long: Offset = &H3C
        Dim FFile       As Long: FFile = FreeFile
        Dim FileData()  As Byte
        
        Open FilePath For Binary Access Read As #FFile
        
        ' Get the offset to PE signature
        ReDim FileData(3)
        Get #FFile, Offset + 1, FileData
        Offset = FileData(&H0) * 256 ^ 0 Or FileData(&H1) * 256 ^ 1 Or _
                 FileData(&H2) * 256 ^ 2 Or FileData(&H3) * 256 ^ 3
        Erase FileData
        
        ' Read the file bitness signature using the above PE signature offset
        ReDim FileData(5)
        Get #FFile, Offset + 1, FileData
        
        If FileData(&H0) = &H50 And FileData(&H1) = &H45 And FileData(&H2) = &H0 And FileData(&H3) = &H0 Then
            If FileData(&H4) = &H64 And FileData(&H5) = &H86 Then GetFileBitness = x64_64BIT
            If FileData(&H4) = &H4C And FileData(&H5) = &H1 Then GetFileBitness = x86_32BIT
        End If
ErrHandler:
        Close #FFile
        Erase FileData
        
    End Function