3F
Can not Load x64 dll, always return null handle. But x86 not.
DllExport version
1.8.1
Known working version or edition
No response
Environment
(other)
Environment version
MS Office 365 64 bit VBA
What happened or what did you expect to happen?
While testing DLLs in VBA projects with different architectures, I noticed something that I think is a bug.
Try loading DLLs (x86+x64) compiled with DllExport into memory using the Kernel32 / LoadLibrary method.
An x86 DLL (32-bit VBA) will return a non-null Library Handle, and your method will work.
However, an x64 DLL (64-bit VBA) always returns a null Library Handle.
Here are the VBA codes (64 bit declaration):
Private Declare PtrSafe Function LoadLibraryA Lib "kernel32.dll" (ByVal dllName As String) As LongPtr
Sub Test()
' will return '0'
Debug.Print LoadLibraryA("SomeFolder\net9.0\x64\ClassLibrary1.dll")
End Sub
DllExport configuration
Installed: True; 1.8.1.36569+c2d3cd1; invoked:
Project type: Cs
Storage: ProjectFiles
Compiler.Platform: x86x64
Compiler.imageBase:
Compiler.imageBaseStep:
Compiler.ordinalsBase: 1
Compiler.rSysObj: True
Compiler.ourILAsm: True
Compiler.customILAsm:
Compiler.genExpLib: False
Compiler.peCheck: PeIl, Pe32orPlus
Compiler.patches: None
Compiler.refreshObj: False
PreProc.Type: DebugInfo, IgnoreErr, ILRepack, MergeRefPkg, Lib
PreProc.Cmd:
PostProc.Type: None
PostProc.ProcEnv: $(SolutionPath);$(MSBuildThisFileFullPath)
PostProc.Cmd:
AssemblyExternDirectives:
TypeRefDirectives:
TypeRefOptions: None
RefPackages: System.Memory,4.6.0,netstandard2.0;System.Runtime.CompilerServices.Unsafe,6.1.0,netstandard2.0;
SignAssembly(Debug):
PlatformTarget(Debug): AnyCPU
TargetFramework(Debug): net9.0
TargetFrameworks(Debug):
TargetFrameworkVersion(Debug):
TargetFrameworkIdentifier(Debug):
RootNamespace(Debug):
AssemblyName(Debug):
DebugType(Debug):
Optimize(Debug):
DebugSymbols(Debug):
SignAssembly(Release):
PlatformTarget(Release): AnyCPU
TargetFramework(Release): net9.0
TargetFrameworks(Release):
TargetFrameworkVersion(Release):
TargetFrameworkIdentifier(Release):
RootNamespace(Release):
AssemblyName(Release):
DebugType(Release):
Optimize(Release):
DebugSymbols(Release):
Identifier: A2DA65F9-2763-48E5-B292-A019EC72F8B8
Instance: C:\Program Files\Microsoft Visual Studio\2022\Professional\MSBuild\Current\Bin\amd64\MSBuild.exe
Project path: C:\Users\zeki\Desktop\ClassLibrary2\ClassLibrary2\ClassLibrary2.csproj
Action: Configure
MgrArgs: -packages "C:\Users\zeki\Desktop\ClassLibrary2\" -sln-dir "C:\Users\zeki\Desktop\ClassLibrary2\" -dxp-version actual -action Configure
MetaLib: tools\raw\lib\net20\DllExport.dll
MetaCor: tools\raw\lib\netstd\DllExport.dll
Proxy:
StoragePath: .net.dllexport.targets
ddNS: ClassLibrary2
ddNS max buffer: 500
UseCecil: False
intermediateFiles: False
timeout: 30000
Options: None
RootPath: C:\Users\zeki\Desktop\ClassLibrary2\DllExport\
PkgPath: C:\Users\zeki\Desktop\ClassLibrary2\\\DllExport\
SlnFile:
SlnDir: C:\Users\zeki\Desktop\ClassLibrary2\
DxpTarget: tools\net.r_eg.DllExport.targets
MsgLevel: Debug
LockIfError:
Attach relevant logs if applicable
No response
Code of Conduct
- [x] I agree to follow this project's Code of Conduct
Thanks for the report! Could you please clarify, is this only reproducible with MS Office?
I don't have MS Office, so... I need more time to check this later. Thanks
Based on your message, I tested it with both C# and C++. Surprisingly, it worked on every architecture. However, I still don't know what the problem is with VBA.
The only thing I've noticed in the projects is that the handle numeric value for the x64 DLL is smaller than for the x86 DLL. Or is it just me?
All Projects:
Screenshots c#:
Screenshots c++;
0x400000 points to the ImageBase and this is known behavior for your configuration; When it is necessary, ImageBase + *Step can be configured in the Wizard starting with 1.8. Must be 0x10000 aligned.
*Step affects multiple targeting via TargetFrameworks.
I've checked using LibreOffice; Long instead of LongPtr should fix the problem:
Private Declare PtrSafe Function LoadLibrary Lib "kernel32.dll" (ByVal dllName As String) As Long
MsgBox LoadLibrary("<path_to>\ProjectS\ClassLibrary1\ClassLibrary1\bin\Debug\net9.0\x64\ClassLibrary1.dll")
' 4194304
Note: you don't need LoadLibrary for the case like
Private Declare PtrSafe Function Deneme Lib "<path_to>\ProjectS\ClassLibrary1\ClassLibrary1\bin\Debug\net9.0\x64\ClassLibrary1.dll" () As Integer
MsgBox Deneme()
' 10
I don't write any mistake with 32- or 64-bit declarations, i.e., Long/LongPtr types. If I had used Long instead of LongPtr, it would have thrown a variable overflow exception.
Let me summarize the problem again. With the current ImageBase/Step settings, a handle can be successfully retrieved from the x86 dll using the Kernel32 "LoadLibrary" method. However, the x64 dll returns a null handle. The problem will go away if the non-null handle is returned from x64 dll.
By the way, Are you sure you've checked in 64-bit LibreOffice? Your ImageBase+Step suggestions unfortunately didn't work.
If I had used Long instead of LongPtr, it would have thrown a variable overflow exception.
Oh right, in VBA it is Long and LongLong
Are you sure you've checked in 64-bit LibreOffice?
Yes, scalc.exe is 64-bit according to magic is PE64 (0x20B) and in About it says x86_64; But it looks like LibreOffice does not support LongLong at all https://help.libreoffice.org/latest/en-US/text/sbasic/shared/03103600.html
That's more like even for 64-bit they use 32-bit VBA engine etc or I don't know the reason why LongLong is not supported but it does not matter if this leads to "Unknown data type LongLong" anyway.
Seems like I still need MS office. It there any trial or something to check it for free?
You can try it here...
https://support.microsoft.com/en-us/office/download-and-install-or-reinstall-office-2021-office-2019-or-office-2016-7c695b06-6d1a-4917-809c-98ce43f86479
@Zeki-Gursoy
... before installing Office for the first time, sign in with an existing or new Microsoft account and enter your product key
I don't have a product key and obviously I need the offline version because web installer is blocked for me due to RegionalBlocks error. BTW FYI, I won't try to bypass this restriction because I don't want to be blocked from GitHub. Sorry. Let me know if MS still provides a standalone installer; I mean, maybe there are still no RegionalBlocks just to reproduce and debug your issue. Thanks.
Regarding the problem,
Clearly the marshalling is incorrect but I don't know the reason for that without actual debugging. This could be simply due to incorrectly used types in your VBA script; at least this explains the empty values because, for example, for the values stored at the highest address ~ 00 00 00 00 FF FF FF FF you will get nothing for the first 4 bytes; or maybe it is VBA engine itself, don't know.
So, what about LongLong type? Try to change all LongPtr as LongLong. What will be the result of this? Also what the result if you will try to export long, ulong, int, uint, short, and ushort types for VBA? Try to get the result using PtrSafe Function declarations. For all these types please try to use LongLong, Long, and Integer respectively