Compact RIO C++ DLL Bad Image Errors in Windows

[impala454]

I'm using a cross compilied C++ DLL in a LabVIEW project which is being deployed to a Compact RIO 9025.  My Project listing shows the cRIO properly and I have a vi under it which depends on the C++ DLL.  Every time I open the vi, I get the following error:

LabVIEW: LabVIEW.exe - Bad Image

C:\path\to\my\libraryfile.dll is either not designed to run on Windows or it contains an error.  Try installing the program again using the original media or contact your system administrator or the software vendor for support.  Error status 0xc000012f.

The thing I think is strange about this, is the DLL is not supposed to be run in Windows at all, so why does LabVIEW complain about it?  It's clearly under my cRIO chassis and related vi.  When I build and run on (and copy the dll to) the target everything runs great.  Is there a way I can get rid of this error?

[RichieTheBard]

The problem here may come from the fact that the cRIO9025 is running a VxWorks OS, which use .out files for using external code, instead of DLLs. The following document provides a little more information about this, as well as a link for creating this .out files.

http://digital.ni.com/public.nsf/allkb/2EA49B05E67DDECF86256F9A006FB315?OpenDocument

You can also check the following link, which details the OS that's used by NIs' different Real Time controllers.

http://digital.ni.com/public.nsf/allkb/35F1FD98520D6E0E8625783A005AF557

[impala454]

Thanks for the reply Richie.

I tried changing the file extensions and it doesn't matter.  I'm properly creating the files using a VxWorks cross compiling toolchain.  The code itself runs on the cRIO and works great.  The error in Windows is what's annoying.  Every time I open the vi, LabVIEW pops this error telling me that file (whether it's dll or out) cannot run in WIndows.  Well duh, I don't want it to run in Windows!  I just feel like the error makes no sense when my dll is clearly under the Compact RIO branch of the project and should never be run on WIndows in the first place.

Here's my project, clearly the AddNumbers.dll (which is compiled for VxWorks) is under the CRIO's tree in the project, so why would Windows attempt to execute it or load it?

And here's the error it shows

[RichieTheBard]

You are right in that this doesn't seem to make sense, and I haven't seen previous causes where LabVIEW tries to call the DLL in the RT target in this way. The error code 0xc000012f doesn't really indicate anything about why LabVIEW may be throwing this error, since this is a Windows error indicating that the file being used doesn't have the correct format, which makes sense since this DLL is not made for windows, but it doesn't really explain why it is being accessed.

Have you seen if this same thing happens when you run this on another computer. If this error seems to occur in other system, I would also consider reinstalling the software in the cRIO.

[rolfk]

That's expected behavour. When you open the VI in your project, eventhough it is in the cRIO part of your project, you do open it under Windows and in order for the VI to be correctly loaded LabVIEW will try to find and load the shared libirary file that is referenced inside the Call Library Nodes. Once you hit the run button or chose to deploy the code the VIs are crosscompiled and send to the target.

If you enter <mysharedlib>.* as library name LabVIEW will replace the ending with what is necessary for the current target, (*.out) for VxWorks targets during compile but will try to load a (*.dll) file when loading the VI, since the loading happens under Windows. If you don't have a *.dll file for your shared library then you get this error. And no, calling an *.out file *.dll doesn't make it a DLL, Windows is not able to load such a file as shared library, which is why you get that error.

Depending on your library it may be feasable to have a Windows version too. If that is not the case and you want to get rid of that error when loading your VIs, you need to create a dummy DLL. This DLL is called the same as your *.out file but with the ending *.dll, and needs to be a valid Windows DLL executable image (so created with Visual C or similar). It must export the same functions as your *.out shared library (at least the ones you reference in your Call Library Nodes), but the functions itself can be totally empty as they won't really be called unless you happen to try to call those VIs from the MyComputer part of your project or target in your project that is one of the older cRIO that runs Pharlap ETS..

[impala454]

Thanks Rolf.  I definitely understand the difference between an "out" file (this makes us non-LabVIEW C developers smack our forehead) and a Windows dll and how to compile for WIndows (or Linux in my case) vs VxWorks.  I just think it's rather silly to *have* to compile something for Windows that I'm never going to actually run in Windows just to satisy an error box.  LabVIEW supports the functionality to call a library function on the remote target and manually specify the data types, so I feel like this is a bug in the software (admittedly I'm running LabVIEW 2009 but for a good reason, I don't know if the same behaviour occurs on newer versions).  I suppose I'll just begrudgingly create the silly stub dll so my LabVIEW counterparts don't whine at me about the error box.  I appreciate the responses guys.

This does kinda follow into another question I posted, the annoyance that the dll/out file/*.whatever file doesn't get copied to the target even though it's listed as a dependency: http://forums.ni.com/t5/LabVIEW/Deployment-of-C-DLL-to-Compact-RIO/m-p/3159636#M911215

[rolfk]

Your LabVIEW version definitely is part of the problem. Newer versions are more friendly in this aspect.

As to automatically downloading shared libraries to the target, that is a tricky part. Shared libraries generally need to be stored in specific locations, (that are at least under Linux RT also highly user configurable) and downloading it automatically might seem to work fine but cause very difficult to debug issues when an older version is already present in one of these locations and gets loaded instead of the new one.

Also on Linux RT shared libraries are only guaranteed to be findable by the shared library loader, that LabVIEW uses, when placed in one of those locations and then running ldconf to update the shared library loader cache. It sometimes works without this step but I haven't been successful in determining why, so always do that ldconf step anyways.