Access Violation 0xC0000005 When Deploying a LabVIEW Executable

[rg81]

Hi,

I am building an exe VI on Labview 2015 (64-bit) (which runs on Windows 7 64-bit). The program uses dlls to communicate some peripherics (an optical spectromenter) and it has some more usb modules (NI card, Arduino, etc). 

The software works well when not compiled into an exe file. Once complied and run on a Windows 7 (32-bit this time) it gives quite randomly the error "Exception: Access Violation 0xC0000005".

While looking on the NI support, I found this: https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P8WkSAK&l=fr-FR

But I do not quite understand how to do it what suggested... the dlls I am using are a folder together with the labview VIs... what should I do then? Should I change their position to the  C:\Windows\ folder and then in the Call Library Function and change the path with %windir%\...?

I am attaching the error message and its description that was in the Labview Data Folder.

Thanks for your help,

Roberto

[rolfk]

---

@rg81 wrote:

But I do not quite understand how to do it what suggested... the dlls I am using are a folder together with the labview VIs... what should I do then? Should I change their position to the  C:\Windows\ folder and then in the Call Library Function and change the path with %windir%\...?

I am attaching the error message and its description that was in the Labview Data Folder.

Thanks for your help,

Roberto

---

No you shouldn't blindly move DLLs around. But can you tell us which DLLs are present in de application folder? There are some that have simply no business to be in your application folder. Any DLL that comes with a standard Windows installation in System32 belongs to that category. But without knowing what sort of DLLs you have in your application folder we can't tell you any conclusive advice.

Generally unless you have a specific installer from a software manufacturer that installs its DLLs into system32 itself you should NEVER move DLLs into system32. Definitely not as a means to fix some crashes.

[rg81]

Dear Rolf,

thanks for your reply. The DLLs are one from Avantes Spectrometer (AS5216.dll) and the second is a labview's one (lvanlys.dll). The issue may be related with this last one?

Thanks for your attention,

Best regards,

Roberto

[RavensFan]

---

@rg81 wrote:

Hi,

I am building an exe VI on Labview 2015 (64-bit) (which runs on Windows 7 64-bit). The program uses dlls to communicate some peripherics (an optical spectromenter) and it has some more usb modules (NI card, Arduino, etc). 

64 bit applications can't run on 32 bit OSes.

Is there any reason you are using a 64 bit version of LabVIEW 2015?  Unless you have some particularly high memory requirements, it is highly recommended to develop with 32 bit LabVIEW.

[rolfk]

---

@rg81 wrote:

thanks for your reply. The DLLs are one from Avantes Spectrometer (AS5216.dll) and the second is a labview's one (lvanlys.dll). The issue may be related with this last one?

---

Pretty unlikely! I build many LabVIEW executables and the lvanlys.dll is always part of such executables and never caused me any problems. Not knowing Avantes in any way I can't say for sure but there is a very good chance that it is the culprit.

You mention LabVIEW 64-bit, so the DLL has to be 64-bit too,but it would be my first suspect for this crash for sure.

Possible problems:

1) a bug in the DLL itself

2) a bug in the Call Library Nodes configuration to call this DLL

3) you mention 64-bit LabVIEW, so the DLL itself has to be 64-bit too or LabVIEW could not load it. But it is very likely that the VIs were developed under 32-bit LabVIEW and possibly in a version before 2009, which was the first to support 64-bit LabVIEW. And then there might be configurations in the Call Library Node that work ok for 32-bit but are not correct for 64-bit.

Contact the manufacturer of this device and ask them to give you the latest LabVIEW library version that was properly tested for operation in 64-bit LabVIEW.

[rg81]

I am sorry, the Labview I am using for creating the exe is 32-bit but on a 64-bit Window 7. Can that create any issue? The PC I then run the exe is a 32-bit Window 7 with the Labview RunTime 2017.

[billko]

Probably the easiest way is to install the Avantes Spectrometer software into whatever machine you are going to install the executable first, then install the executable and let LabVIEW worry about finding the dll.  This involves NOT giving a static path to the dll and to NOT include the dll with your exe install.

[rolfk]

---

@rg81 wrote:

I am sorry, the Labview I am using for creating the exe is 32-bit but on a 64-bit Window 7. Can that create any issue? The PC I then run the exe is a 32-bit Window 7 with the Labview RunTime 2017.

---

That DLL or the LabVIEW VIs for it are still the most likely culprit in this,