error type 6308

[Jaques]

I've created a compiled Labviewapplication that I have installed successfully on a Vista 64 PC and an XP 32 machine, but when I install it on a XP 32 home machine, for an administrator user, the application starts up with the message "VI has an error type of 6308.  The full development version of Labview is required to fix it."  I have searched for error #6308 but cannot find it anywhere.

[mishkin]

Jaques,

That error message can be caused by several different things. To start, does your executable require any additional NI drivers (DAQmx, etc)? Make sure those are properly installed (it may even be a good idea to reinstall them). Also, can you verify what versions of Microsoft .NET framework you have? You should be able to get this from Control Panel > Add/Remove Programs...

[Jaques]

I don't use any other Labview components, and I have 1.0, 1.1, 2.0, 3.0, 3.5 versions of .net installed. 

Here is a long chain of questions that might help:  Is this error .dll related?  If so, I am using FDTI USB .dll calls from my application, if the runtime cannot find required .dll's will it cause this error? 

If so, there is probably a way to check if the .dll is there in the first place.

I have the FTDI driver install package that works for most versions of Windows, how can I launch a .inf install from Labview, so that I can prompt the user to do so?  Or during the install process?

Thanks,

Jacques

[Jaques]

I also have Visual C++ installed on this laptop (that has XP 32 Home), maybe it's installed some debugging .dll's that Labview notices as only being useful for debugging, which isn't allowed in my stand-alone application?

I've also tested my application successfully on a Win2K machine and an XP32 virtual machine, so 4 out of 5 isn't bad.  This is only a utility for us, so it's not important to get it to work on all computers.  If you have any ideas, they would be welcome but otherwise we can close this issue.

Thanks,

Jacques

[Wes_P]

Hi Jacques,

This is a bit puzzling.  Maybe there are some dlls that exist on the laptop (specific laptop drivers, or something like that) that are conflicting with the dlls that you have installed?  I'm not sure I have any concrete ideas for you, but I'm just trying to brainstorm a little.

[Jaques]

I had previously downloaded the drivers from the FDTI site, but as a subdirectory.  But now instead I downloaded their setup.exe driver installation application, and added that to my Labview install sequence, and the problem has been fixed.

[JÞB]

FTDI driver

Been there--- done that

I'm sorry if this comes across as condecending But-- I HAVE Been there--- done that.

 Use a dynamic call to a vi with a CIN that calls the FTDI DLL.

Win-doze garbage collection is poor and (THAT ) DLL caused me DAYS of headaches 

[Jaques · Accepted solution]

The solution I previously said works only works on some computers.  A better solution turned out to be copying all the driver files and .dll's into the directory my Labview application gets installed to, then Labview finds them no problem.  I'm getting my customers to do this manually when they encounter the problem, it's pretty rare.

One problem was that there are AMD64 drivers and drivers for everything else, so my plan (when I have time) is to make a change to my application so that after being installed asks the user whether their PC is AMD64-based or not, copies over the appropriate files, then sets a flag so that it never asks the question again.

[marxious]

I have this exact same error, where I've included my dll into the always included build spec, and I've saw all the related dependencies under my data folder. Now, if I don't copy the file to the same folder level where exe exist, I would encounter 6308 error, but it finds dll no problem if it's in the same folder level. 

[Mike.B]

Hi marxious,

It looks like this thread is from a number of years ago. I would create a new forum post and elaborate upon the information you provided here so that it can get increased visibility in our NI community.