Labview trying to find runtime engine when opening up VB6

[Dauntless]

This is bizarre. I'm not even trying to open a labview program, and I get this error.

when I go to open up VB6 from Visual Studio (Visual Studio 6, Enterprise Edition), I get a pop-up saying that the Labview runtime engine 7.1.1 is going to be configured. A new window then pops up, because it can't find the lvruntimeeng.msi file.

Problem is, I'm using Labview 8.2.

Worse, now my VB6 programs are hanging if I close out of all the installer boxes (it does this multiple times).

UPDATE-4:42PM EST-
I noticed when I went into Add/Remove Programs in the control panel, when I clicked on Change for National Instruments, it says that only the 7.1.1 Runtime Engine is installed. However, I can not uninstall it because another product relied on it. I also downloaded the 7.1.1 runtime engine, but it doesn't install because it says a higher version is already installed. (?)

Message Edited by Dauntless on 12-26-2006 03:46 PM

[tst]

There are some NI programs which were written in LabVIEW and so need the LV RTE in order to run.

Theoretically, the RTE should be properly installed when these programs are installed, but for some reason maybe it wasn't. Maybe one of the NI services running on your machine tries to do something when you're opening VB or maybe your code calls some NI component?

I used to have something similar where for some reason going into certain websites prompted me to insert the LV 7.1 CD so that I can configure the RTE. I think it stopped after doing it one time.

You can try downloading the 7.1 RTE and installing it to see if it will stop. If not, you can try pointing the dialog at the MSI once to see if that will stop it.

[Dauntless]

When I try to open up any VI files, Labview is also now hanging. It tries to find a particular .dll file that this VI links to, and while it is searching for it, it always hangs on c:\program files\national instruments\labview 8.2\instr.lib\Agilent 34401\public\utility

when I browse to this directory, there are a couple files. So I'm not sure if maybe one of them is corrupted?

Secondly, why is it always searching for the .dll? It is in the computer's system path. Do I have to set it somewhere in Labview manually?

[tst]

Does this happen in all VIs or only in VIs which call functions from this DLL?
I'm assuming only VIs which call this DLL.

Basically, LV saves relative paths to files. For example, it saves the path to the DLL as "go up two levels from where this VI is saved, find a directory called "whatever" and look for the DLL in there".
If you move the VI to another directory, LV will not find the DLL where it expects to find it and will start searching for it in some defined search locations.

I'm not sure why it hangs, though. If LV goes through all the search locations without finding the DLL, it should pop up a dialog asking you to locate the file.

[Dauntless]

Yeah, any VI which calls this dll causes LabView to hang.

I sort of semi-solved the hang problem though. I took the offending dll out of C:\Windows\system. But now, when LabView tries to find it, I browse to where the dll is located (two directories up from this particular VI) and I get an error message saying there's a memory access violation. So Labview can't load it.

Perhaps the dll is already loaded from another program?

[tst]

I can't say I've seen something like this, and if I'm not mistaken, Windows is supposed to allow each process to load its own copy of a DLL (at least for threadsafe ones), but I would suggest searching the site for details of this error.

Is this your DLL or a Windows DLL?
Can you try renaming it and seeing if you can load it then?