Runtime Support for Calling DLLs

[Gregory]

I have an application that works as expected on most PCs I've installed it on (~20), but on a couple it claims it cannot find a DLL that is called. This DLL was made by a colleague and gets put in the "data" folder next to the executable. 

So far I'm not sure what is different on the PCs where I get the error. I'm guessing it's not getting some of the runtime support that it needs, but I'm not sure. The installer is supposed to install the automatically selected "additional installers":

NI LabVIEW Runtime 2016 f7

NI-488.2 Runtime 16.0

NI-VISA Runtime 23.3

When I run the installed application after a bad install, I get 4x "resource not found" messages and then a long paragraph about 2208 errors.

[rolfk]

what compiler and version did your colleague use to create that DLL?

[Gregory]

Hi Rolf,

I believe the DLL was written in C++ and compiled using Microsoft Visual Studio 2013. 

I am not very familiar with C++ or creating DLLs. Is that the information you were asking about? 

(Off-topic, but several years ago you helped solve a bad memory leak issue with this exact DLL, thanks again!)

[rolfk · Accepted solution]

---

@Gregory wrote:

I believe the DLL was written in C++ and compiled using Microsoft Visual Studio 2013. 

I am not very familiar with C++ or creating DLLs. Is that the information you were asking about? 

---

Yes! Microsoft Visual Studio 2013 and earlier used version specific Microsoft C Runtime libraries. Back in Windows 7 days you almost automatically had the according Runtime library installed since Windows 7 is for large parts compiled with Visual Studio too.

However nowadays with Windows 10/11 the chance that one of the older Microsoft C Runtimes is already installed on a particular system gets smaller and smaller. Microsoft itself won't do that really so it all depends what other applications are already installed on a system. If one of them was created with your Visual Studio version you are lucky, otherwise you need to make yourself sure that the correct Runtime is installed.

For Visual Studio 2013 you would need this:

https://www.microsoft.com/en-us/download/details.aspx?id=40784

Basically your collegue who created that DLL should also have created an installer that also includes the correct C Runtime Redistributable installer and launches is during installation.

[Gregory]

That's great, thank you! I installed the "x86" one and now my DLL is magically found. 

[Gregory]

As an aside, I actually already included the C++ redistributable in a .zip file with my LabVIEW installer. But, in Windows 7 I got an error that said "MSVCR120.dll is missing". In this case, I googled what that was and realized the C++ redistributable was needed. In Windows 10 / 11 the error message says that my own DLL was missing, which really led me on a wild goose chase 😅

[rolfk]

Windows LoadLibrary() doesn't really return any specific error as to why loading failed. It simply states that loading the library did not succeed. NI has had in there some tricky workarounds to try to detect the possible reason for failure but that part of Windows is prone to various changes across Windows versions. Windows APIs generally are only very unspecific about what errors they can return and for what situations. It's a lot like: If it succeeded the return value is TRUE, or for some functions also NO_ERROR0 or similar, otherwise there was an error.

While you can try to interpret the various error codes for a specific function, or go even more into trying to exploit side effects of APIs to determine something more, it is very error prone across Windows versions, as Microsoft generally does not guarantee that a specific situation will always return the same error code. And trying to interpret string results of errors is even more tricky because of the localization of such resources and the possibility that such strings will be reviewed and changed for various reason with new Windows versions.

They can for instance try to see if the DLL file is there after LoadLibrary() returned an error but that is still not safe, it could be an empty file, or a text file with that name and that would mean that the detection logic says that since the file is there, it must be a dependency problem, but that would be a wrong conclusion. At some point you simply have to stop trying to be smarter than what the API that you are using will provide you with.