"Spherical Bessel Function jn.vi" not found in built app

[Dennis_Knutson]

On your "clean" pc, in the folder that you installed the app to, is there a folder called 'data' and is the dll in there? That is the location that the built app expects to find it by default.

[MattI]

Yes, I did all that.  I have lvanlys.dll in the same dir as the .exe, as well as in the data folder.

[MattI]

OK, I finally got it working.

I had to install NI-DAQ in order to get the above built-in VI ("Spherical Bessel Function jn.vi") to work!

I installed NI-DAQ 7.4.1 Traditional w/ all language options selected (including LabWindows/CVI).  Because I selected support for all languages, I'm not sure what was required.  But I'm guessing it was LabWindows/CVI!

Here's why:

On some other machines that had problems with some missing math functions, I noticed that there were some error messages that cvirt.dll wasn't present.  The only place I could find this dll mentioned in the NI website was w.r.t. LabWindows/CVI.**

It would be nice if all of the math functions, when they fail to find a dll, reported which dll it was they were looking for but could not find.  Particularly if the location has (apparently) changed b/w one version of LV & another (as seems to be the case for LV7.1 vs. LV6.1).

It would also be helpful if the NI website mentioned which dlls are installed with which software, and which are required by what functions (or at least what NI calls "packages").

Without these kinds of things, it's hard to recommend to others within my company that LabVIEW is a user/programmer-friendly environment with good enough error messaging & support documentation that it is superior to the many other solutions out there on the market.

-- Matt I.

See, for example, the following articles:

http://digital.ni.com/public.nsf/allkb/1b9dd6b42eeef282852563850069e46b

http://www.ni.com/labview/last_upgraded.htm 

http://digital.ni.com/public.nsf/allkb/d3efe7c6f073384886256fdd005fbcda

Note that these articles are merely the subtlest of clues that the math functions which I've been hunting for (well, LV7.1 is hunting for) are actually supported by cvirt.dll & cvirte.dll on a system that doesn't have the development software & therefore which the built app must have present.

[THailey3]

Hi Matt,

Sorry to hear that you had so much trouble upgrading your application.  Efosa should have replied with more specific information on what he tested and what his results are.  I did some further testing, which indicates there was something wrong specific to your machine:

Test 1: I created a LV 7.1 executable that simply calls the Spherical Bessel Function jn.vi (which calls the lvanlys.dll).  I reimaged a PC to only WinXP and then installed the web-downloadable LV 7.1 RTE.  The executable ran as expected without any errors on this clean machine.

Test 2: I downloaded Bessel_funcs.txt and changed it to an exe file.  This same executable runs as expected without any errors on my clean (LV 7.1 RTE only) machine.

From the error dialog in your previous post (err_msg.PNG), it appears that for some reason, the lvanlys.dll was either not loaded or had problems loading.

To summarize:  It isn't clear to me exactly what was going wrong on your machine, but it is clear that the problem was specific to the setup of your machine.  I suspect at some point, some files got shuffled around or installed/uninstalled incorrectly.  I also suspect that reinstalling NI-DAQ updated some common files during installation.  This could be specific to the lvanlys.dll or the LV 7.1 RTE in general.  I'm pretty sure installing NI-DAQ 7.x also installs the LV 7.1 RTE, so it may have repaired the missing/corrupt files.  I suspect that simply reinstalling (probably even just repairing) the 7.1 RTE would have fixed your issues.  This should remove any suspicions that there is a dependency between the Spherical Bessel Function jn.vi and LabWindows/CVI.

Hope this helps,

[MattI]

Thanks for taking the time to go from a clean image.

I think you're mistaken about the issue being the runtime engine is corrupt on an isolated machine.  Well, at least it's certain that it is not isolated to a single machine, because we've seen this behavior on many PCs ("this behavior" meaning always requiring NI-DAQ 7.4.1 to be installed for the .exe to work.)  We also did uninstall and reinstall the RTE7.1 (on 1 PC, anyway) several times as a (failed) experiment.  Lastly,  when we've had similar trouble on various machines, some were totally "clean" w.r.t. pre-existing NI software other than the install of the 7.1 runtime engine (via an installer program that I wrote using the app builder).  (Others already had 6.1 RTE, NI-DAQ 7.0.1, some version of NI-VISA, & NI-488.2 v. 2.3.)

However, for most .exes, if the required dll wasn't found, the built app reports that it couldn't find the required dll (not that this really helps a lot, because there's no indication which NI software installs which dll.  Nonetheless, I figured out that it was NI-DAQ that fixed it anyway.).  For example, on a certain machine, one of the math functions I used (I can't remember which at the moment, but it wasn't a Bessel function) required NI-DAQ 7.4.1 install (there was no NI-DAQ installed previously, by the way), and prior to that it install it did say that it couldn't find cvirt.dll.  (Note that my app was only using a math function, not LabWindows/CVI.)  But for the above function ("Spherical Bessel Function jn.vi"), it doesn't report the specific dll that couldn't be found (it instead says, as you know from err_msg.png, that "an external subroutine" can't be found).  However, it does require (& in fact, any time it is run, creates) the dll advpack.dll in WINDOWS/system32/ or system32/dllcache.

The only thing I can think of to reconcile the differences we're seeing b/w our end and yours is this:

The runtime engine that is created by the installer freature of the app builder (or my app builder, anyway) is defective or incomplete, and requires NI-DAQ to fix or "complete" it.

I'll try what I sent you again, on a "clean" machine, but this time the runtime engine 7.1 that I install will be the one from the NI website, not from my app builder install.

[THailey3]

Hi Matt,

I think there is some confusion as to what actually is occurring on your machine(s).  There is no dependency between the LabVIEW analysis VIs and NI-DAQ or LabWindows/CVI.  Installing these products should not have any direct effect on the behavior of your executable unless it is updating shared components that are on your machine (i.e. the LV 7.1 RTE).  As for the advpack.dll, it is not an NI file, but is required by Windows (see here for more details).

You mentioned that the 7.1 RTE you were using (when the exe failed) was installed by an installer that you created with LabVIEW 7.1.  When you created the installer, did you make sure to click the Installer Settings Tab>>click Advanced>>and select LabVIEW Run-Time Engine along with each of the subcomponents.  Maybe you did not include "Analyze VIs Support"?  If you did not check this option, then your installer would install a "custom" LV 7.1 RTE without this support.  This would explain why any applications that used analysis VIs did not work on your deployed machines.  I would first try rebuilding your installers with this support.

Also, as you mentioned, downloading the LV 7.1 RTE from ni.com Drivers and Updates: LabVIEW Run-time Engine Version 7.1 for Windows 2000/NT/XP automatically includes all support and doesn't allow you to customize the support installed.  I would try installing the LV 7.1 RTE from here and making sure your executables work. 

I suspect that the root problem was merely the fact that the LV 7.1 RTE, installed on the machine(s) with problems, did not include "Analyze VIs Support."

[Travis_M.]

Another thing to note, is that is possible that the lvanlys.dll file is dependant on other dlls being present.  I.e. as of recently, both LabVIEW and CVI use the Intel MKL (math kernel) for some advanced mathematical functions.  It is possible that the lvanlys.dll could load because it was included as a resource file, but the Intel MKL was not installed because of the particular setup of the test machine.  I'm not exactly sure how your program would fail in this case (whether it would give a message or not), but it could be a source of problems.  Also, there could be problems with multiple versions of LabVIEW being installed -- for example, if you include the analysis dlls from version 8 instead of the ones from version 7. 

Also, to clarify a point above that Travis H made, because this problem doesn't occur on every computer, we suspect that the issue is related to a software install/config problem which is why we are asking you the questions about how your runtime engine is installed, etc...

Thanks for taking the time to debug with us -- hopefully we can determine exactly how this occurred.  Have a great afternoon-

[MattI]

You guys ain't gonna believe this....

When I put the file lvanlys.dll in the same directory as the executable, it's broken upon loading (giving the same errmsg as I uploaded before)!

If I remove lvanlys.dll, the .exe works fine!

If I put lvanlys.dll back, it's broken again!

It's repeatable all day long!  Try it yourself!

This was true whether the files were on the desktop, in C:\temp, or on a networked drive.

Now, the other question is, why does installing NI-DAQ *FIX* this bizarre behavior???

[NathanT]

MattI,
      Did you have a chance to try including analysis VI support in your installer, or installing a LV 7.1 Run-Time Engine from our website, like Travis H. suggested?  The executable is looking for the dll in a certain location, which is not in the same folder as the executable, which would partially explain the behavior that you noted in your last post.  Please let us know how it goes with the full Run-Time engine from the website or including Analysis VI support in the installer.

Thanks,

NathanT
      

[MattI]

Why aren't I being understood here?

The issue has nothing to do w/ the options in LV app builder, or installing the RTE from the website on a totally clean image.

I did all of the suggestions, but none of it has demonstrated different behavior at all.

Let me restate: if & only if the lvanlys.dll is added to the same directory as the .exe does the error occur.

I find it rather outlandish that anyone would think that it is acceptable software behavior for unnecessary files to not be allowed to exist in the same directory as the executable!

If NI-DAQ is installed or LabVIEW development software is present on the system, the issue does not occur.

If I create a "fake" lvanlys.dll (i.e., a file by that name but it contains nothing), the .exe does reference it as evidenced by the fact that it complains.  The error message is attached.