From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabWindows/CVI

cancel
Showing results for 
Search instead for 
Did you mean: 

Passing address of function in DLL back to caller causes crash

The main program loads the DLL with LoadLibrary() and then uses GetProcAddress() to call a function in the DLL. This function then passes a table back to the main program. Included in the table are addresses of functions in the DLL that the main program will call at a later time. The problem is that when the main program is in release mode, the DLL moves around in memory and the function addresses cease to be valid. Things work fine when the main program is run in debug mode. Is there a simple way to force the memory relationship between the DLL and the main program to remain constant, perhaps in the same way that CVI does it in debug mode? If so, is it a reasonable thing to do? The DLL has shell code that wraps
a set of functions whose names are not a priori known to the main program. If necessary, I can change the shell code to use a known linking function within the DLL to call the appropriate function in the table. However, there are a number of such DLLs and for a number of reasons I would prefer a fix in the main program.
0 Kudos
Message 1 of 2
(2,603 Views)
Hello

Im not sure what you might be able to do about this from CVI, since its pretty much up to the OS how and where the dll is loaded in memory. I would think that when the code is run in debug mode, the CVI enviornment is making sure that the memory locations are valid. Perhaps what might be happening is that there is already a process loaded at the image address of the dll, and thats why the OS moves it elsewhere to an available location. Which is why perhaps rebasing the main dll to an un-used memory location might help.

Or perhaps you could delay the process of loading the dll address table until after most of the initialization has occured.

I hope thi
s helps

Bilal Durrani
NI
Bilal Durrani
NI
0 Kudos
Message 2 of 2
(2,603 Views)