Error 1556 When Running GPU Analysis as Executable

Issue Details

When I try to run an executable that I created using the GPU Analysis Toolkit, I get an Error 1556 such as the one below. I'm running the program on my development computer, and this error does not occur when running the development code.
  Error 1556 Occurred.
Possible reason(s):
LabVIEW: (Hex 0x614) The reference is invalid. This error might occur because the reference has been deleted.  

GPU Analysis Information: A GPU resource is invalid.

Cause: Creating a GPU resource failed.
Solution: Make sure the resource request was for a valid device. If so, check to see if the device supports the type of resource being created or has the amount of physical resources available to honor the request.

Cause: A GPU resource has been deleted explicitly.
Solution: Only delete the GPU resource after all processes using that resource are finished with it.

Cause: A GPU resource has been deleted implicitly.
Solution: Avoid replacing an existing GPU resource with a newly created one in situations where the resource is being cached (e.g. passed to a shift register).


What is this error, and how can I resolve it?

Solution

Why the error?

Building a stand-alone application with LabVIEW that includes GPU computing uses external libraries, but it only knows about those libraries called from CLNs (Call Library Function Nodes) where the library name (and possibly path) are hard-coded in the node. For the GPU toolkit  to support multiple CUDA versions and different Windows platforms (i.e. 32- and 64-bit versions) from a single API, certain libraries are identified at run-time and passed to the CLN for execution. This is (a) how an lvcuda*.dll library is used in the LVCUDA API and (b) why they do not show up as a dependency like other external libraries (e.g. lvgpu32.dll or lvgpu64.dll).

The Fix

The GPU toolkit installs lvcuda*.dll in a lvgpu folder under LabVIEW's resource directory. This is part of the default path LabVIEW uses (in the development environment) to locate external binaries. No such default directory exists once you build a stand-alone application. However, there is still a search path used by the executable to find binaries it needs. The details regarding this can be found at Executable Cannot Find My DLL Even With A Specified Path . Sometimes it's valuable to find out what dependencies these binaries have (e.g. a library which is itself linked to another library). The article Determine What Calls Are Made by My DLL or Executable in LabWindows™/CVI™ discusses how to track such dependencies.

While these resources describe a few ways to make external libraries work from a stand-alone application, copying the external libraries to the system directory appears to be the most straightforward and yields success 100% of the time as long as the DLLs are put in the proper place.

For a 32-bit app, copy lvcuda32.dll to <windows_root>\system\lvgpu. For a 64-bit app, copy lvcuda64.dll to <windows_root>\System32\lvgpu. The 'lvgpu' subdirectory is required as this is the folder structure used inside LabVIEW's resource directory. Note that you do not have to do anything special with lvgpu32.dll or lvgpu64.dll. These libraries are recognized as dependencies and the VIs that call them will automatically look for them in their new location based on the build specification.

Alternatives

If copying files to the system directory is not an option, the executable can look for libraries using the PATH environment variable. Appending the library location to the PATH can have unintended consequences or encounter other problems (e.g. too many characters on 32-bit OSes) so it's not always a fail-safe or recommended approach.

Copying the libraries into the run-time engines folder may also work, but this is modifying a Program Files folder. Whether these changes persist during some installation modifications is undefined. In addition, you'd need to copy the libraries to each version of the run-time engine your application is built against.

Additional Information

​​​​​