Access violation with DeclareLibraryMBS

Extras
1

So this is from the opening event of an app where I want to access a 3rd party USB measurement device. Reading of the SymbolNames is just for debugging, and it works on macOS and Windows 10/11. (on macOS there‘s hundreds of them, and most don‘t look ok. On Windows I see the method names as expected from the API documentation.)

Anyway, invoking the DeclareFunctionMBS f1 only works on macOS where I get the string of all possible instrument connections. On Windows, the app crashes fully and I am told about an access violation but have no idea how to investigate it further.

Interestingly, setting up the DeclareFunction works on macOS and Windows – I get valid addresses for the method pointer. It‘s only the invocation of it that will crash on Windows.
How can I find out what‘s really happening? dbgView does not record anything.
And any idea what is happening at all? I would not expect such a hard crash on a valid method address.

Static mextlib As DeclareLibraryMBS
#If TargetMacOS
  var f As FolderItem = tpsf.Frameworks.Child("libeXact2.dylib")
  mExtLib = New DeclareLibraryMBS(f)
#ElseIf TargetWindows
  var f As FolderItem = app.ExecutableFile.Parent.Child("eXact2.dll")
  mExtLib = New DeclareLibraryMBS(f)
#EndIf

var names() As String = mextlib.SymbolNames
var p1 As Ptr = mExtLib.Symbol("GetSettingOptions")
var f1 As New DeclareFunctionMBS("(Z)Z", p1)
var s As String = "Connection_Method"
f1.SetParameters s
s = f1.Invoke
2

Please check calling convention.
DLLs on Windows use StdCall usually, which is different to normal cdecl. Basically the question who cleans up the stack and what orders parameters are passed on the stack or registers.

Maybe add kCallModeStdCall to the declaration.
Or set CallMode property.

1 Like
3

Thank you, Christian! I had been experimenting with CallMode but did not realise the CallMode signature possibility. That fixed it! Thanks a lot!

1 Like