LabVIEW-built Windows EXE requests nisyscfg.dll at startup

[LabVU_Dog]

Hello all,

I've been intermittently experiencing a problem after building a Windows EXE (built and deployed on Windows 7) from LabVIEW 2013 SP1. Occasionally, when I attempt to run the EXE, it will provide a file dialog prompt at startup asking for the file "nisyscfg.dll". If I CANCEL, the rest of the EXE loads and runs fine. Previously, I would just recompile the EXE, and after a try or 2, the problem would go away.

Yesterday I attempted to use the LabVIEW-built installer to install that same Windows EXE on a different Windows 7 computer (different from the computer used to build the EXE and installer). The new target machine does NOT have LabVIEW (any version) installed. Curiously, it now displays the startup error. When I used the same installer, to install on the Win 7 machine used to perform the builds, that EXE does NOT have problem at startup.

Attempting to run and close the application several times does not fix the problem. I also attempted to locate the specific file on the development computer, and copy it to the same location on the target computer. It turns out there are several versions of this file on my development computer. When I directed the EXE to a copy of the file (I tried several versions of the file), it indicated another error, that it couldn't find something in the file, and proceeded to finish loading and executed correctly. I'll have to check again to determine exactly the second error produced.

Any ideas about how to resolve this, other than just keep rebuilding the EXE/installer?

[Dennis_Knutson]

What else besides the exe are you including in the installer. You obviously need for runtime but do you also use any hardware. You would need drivers for that and possibly MAX. You should never just blindly copy files.

[LabVU_Dog]

The application uses no other drivers that I can think of... it is only ethernet communication to another application. The RTE is all. I can double-check that.

[Sam_Sharp]

I think it's the NI System Configuration drivers that are missing - they're most commonly used for interacting with RT/FPGA/hardware targets but I think they can also be used for getting information about installed NI software/MAX configurations.

Not sure why it somtimes is/isn't required but you can always just include the NI System Configuration Runtime drivers in your installer which should stop the error from occurring in either case.

[Hooovahh]

---

@Sam_Sharp wrote:

I think it's the NI System Configuration drivers that are missing - they're most commonly used for interacting with RT/FPGA/hardware targets but I think they can also be used for getting information about installed NI software/MAX configurations.

Not sure why it somtimes is/isn't required but you can always just include the NI System Configuration Runtime drivers in your installer which should stop the error from occurring in either case.

---

Yup this is it.  I've seen this same error and under the Additional Installers I needed to include the NI System Configuration to be included.  I was actually calling the system configuration VIs to query the hardware connected to my system on startup to make sure all was okay before running.

[brian175]

I know that this is an older thread, but I just encountered the exact same problem and wanted to share in case someone else is struggling with finding why they are getting the same error.  In my application I had previously converted my common code (user.lib) to a library and then a packed library.  In the application I use some "utility" VIs, but do not use any VIs that call the system configuration VIs.  However, in the library there is a real time utility that I created that waits for a controller to boot.  Even though the VI is never called, I believe that the entire library is getting loaded and generating this missing dll error.

The solution of including the "NI System Configuration Runtime drivers" does work, but it adds unnecessary bloat to the installer and installs unnecessary NI software on every end user's PC.  In the literature where all of the "benefits" of using a packed library is discussed, this annoying little tidbit is not mentioned.

I beleive that my 2 options are:

1. Install the additional driver with my application
2. Remove the real time utilities from my library

Has anyone else found another solution to this problem?

[rolfk]

It's a documented but maybe not so well known fact that a LabVIEW library is pulling in every dependency it contains, independent if your project makes use of them, if you use anything from that library. A packed library is also simply a build of whatever is in the LabVIEW library and if your program loads something from the packed library the LabVIEW library pulls in everything on load which causes the dialog. It's not ideal but I suppose that the alternative has some other just as undesirable features.