Problems in calling c++ dll with strings after upgrading to LabVIEW 64 bit

[defanbet]

We recently upgraded to LV2025 and since now all packages and drives we need are also available in 64 bit we decided to test a switch to 64 bit aswell;
On the surface level this all works fine and we actually were able to build our application and run it and like 99% of it is still working;

In our code we call a c++ dll to do some hardware interfacing; this dll was originally also 32bit but we just rebuild it for 64 bit;
To do that i upgraded the includes and libraries in the visual studio solution to the ones from: C:\Program Files\National Instruments\LabVIEW 2025\cintools
With that the dll was builable in 64bit without other code changes and can actually also be called in 64 bit mostly;
However with this function here:

We get LabView (in exe and development environment) to crash without any report or anything; Just a access violation can be found in the Windows event viewer; In 32 bit this doesn't happen.

From the c++ side the function definition looks like this: unsigned char __stdcall LVBusGetRxSignalList(LVStringIntArrayHdl out_signals)
with:

// A cluster with a string, and two int

typedef struct {

LStrHandle lvString;

int32 lvID;

int32 lviface;

} LVStringInt;

//typedef StringInt;

// A arraycluster with a LVStringInt

typedef struct

{

int32_t dimSize;

LVStringInt signals[1];

} LVStringIntArray;

typedef LVStringIntArray **LVStringIntArrayHdl;

Basically we expect both structures to still be correct especially since LStrHandle didnt change;

We then write the string from within c++ like this:

LVStringInt signal_info;

int32 len = stringToWrite.length();

LStrHandle handle = (LStrHandle)DSNewHandle(len * sizeof(uChar) + sizeof(int32));

memcpy(LStrBuf(*handle), stringToWrite.c_str(), len);

LStrLen(*handle) = len;

signal_info.lvString = handle;

This all works and actually also doesnt cause the error we see; The error only happens when Labview tries to read the string (name) from the struct again; So the code crashes in the for loop (see LV code above) when we unbundle the structure and access the name; If we onyl access the two integers it works fine;


Based on this it did more tests and simplyfied the call to just use a single LStrHandle and what i found is strange; If u use DSCheckHandle on the handle we get from LabView it returns 3 (mZoneErr) and trying to read the length with DSGetHandleSize will actually also cause a crash; And also no matter what you do in your c++ code and how acuratly you adjust the handle (edit; adjust size; dispose and create new) the code will always crash either in the dll or when accessing teh string in LabView;

For me this looks like a bug in LabView 2025Q3 64 bit as with 32 bit it works and i see no reason why this could or any of my test should crash in 64 bit;
Are there any ideas how to fix this; Am i doing something wrong or is this just a bug?

[rolfk · Accepted solution]

No, I'm using 32-bit and 64-bit compiling for LabVIEW DLLs frequently and have not seen anything that I would consider a bug there.

Do you have anywhere in your headers a definition like #pragma pack(1) or use in your project settings maybe Struct Member Alignment set to 1 byte?

That worked for LabVIEW 32-bit libraries but LabVIEW 64-bit has switched to default alignment.

Basically your LabVIEW struct declarations should be all wrapped into:

#include "lv_prolog,h"

// your LabVIEW structure declarations here

#include "lv_epilog.h"

lv_prolog switches to the LabVIEW required alignment (basically 1 byte for Windows 32-bit and default for pretty much anything else) and lv_epilog resets it to what it was before.

Your project can then use whatever settings the rest of your interfaces would need, most likely default alignment (8-byte) but the LabVIEW structs are then correctly defined no matter what.

[defanbet]

Thank you very much!

that was exactly the issue;

Im not a c++ developer so this makes not much sense to me but we had

#pragma pack(1)

#include "lv_prolog,h"

// our struct defs
// missing #include "lv_epilog.h" line

and now i just removed the pack(1) as we dont need it and added the lv_epilog line and it works fine;

Your fast answer is very appreciated!