Locating the Origin of an Access Violation...

[ChristopherPovey]

I have a LabVIEW 2017 built executable which runs continuously on our test set. Other LabVIEW 2012 VI's interact with this executable via TCP/IP Localhost.

Problem is, every so often, the executable crashes with an Access Violation (0xC0000005) and a EIP address?

The executable contains a third party library and some wrapper LabVIEW code for the TCP/IP bits (to make the 3rd party library more friendly).

I am not sure where the crash is happening! Is there a tool that I can pass the exe file to and the EIP address and it will say the crash is occurring in VI so 'n so? Or is there a tool I can run along side the executable to catch the crash?

Installing LabVIEW 2017 development on the test set is not an option as it will "damage" the LabVIEW 2012 installation.

Thanks.

[Yamaeda]

You can build the executable in Debug mode and remote connect to the VI to follow the flow in real time.

/Y

[rolfk]

Is this third party library DLL based?

[ChristopherPovey]

---

@rolfk wrote:

Is this third party library DLL based?

---

No. It's all LabVIEW 2017 VI's and FPGA Code. Looking at the other files in the dump log there is a text file called "lvlog.txt" this has a call tree of the VI's when the crash occurred. The crash did happen in one of the third party library VI's. I just don't know why. It is intermittent too. So the same VI ran fine for 15 minutes (and over 100 calls). I have contacted the third party company for suggestions.

Thanks.

[Yamaeda]

---

@ChristopherPovey wrote:

---

@rolfk wrote:

Is this third party library DLL based?

---

No. It's all LabVIEW 2017 VI's and FPGA Code. Looking at the other files in the dump log there is a text file called "lvlog.txt" this has a call tree of the VI's when the crash occurred. The crash did happen in one of the third party library VI's. I just don't know why. It is intermittent too. So the same VI ran fine for 15 minutes (and over 100 calls). I have contacted the third party company for suggestions.

Thanks.

---

A classical problem is opening a new connection with every call instead of reusing some reference. Tell us what you find out.

/Y

[ChristopherPovey]

---

@Yamaeda wrote:

---

@ChristopherPovey wrote:

---

@rolfk wrote:

Is this third party library DLL based?

---

No. It's all LabVIEW 2017 VI's and FPGA Code. Looking at the other files in the dump log there is a text file called "lvlog.txt" this has a call tree of the VI's when the crash occurred. The crash did happen in one of the third party library VI's. I just don't know why. It is intermittent too. So the same VI ran fine for 15 minutes (and over 100 calls). I have contacted the third party company for suggestions.

Thanks.

---

A classical problem is opening a new connection with every call instead of reusing some reference. Tell us what you find out.

/Y

---

Possibly. Unfortunately the VI in question is protected so I don't know what is going on inside it! 😞

[bean123]

I would use the desktop execution trace toolkit (DETT)

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P9vgSAC&l=en-US

[Ben]

Is the dll thread safe?

The wrapper may help avoid multiple calls when in the 2017 environment but from the older 2012 environment... not so much.

Another out there thought...

VI server can invoke VI served from an exe can (in theory) span LV versions.

Spoiler

It worked in LV 6.1 and 7.0 when I last tried it.

Serving up and doinga Call by Referecne of an action engine that wraps up the dll in the 2017 version to the 2012 version can ensure the dll is not being invoked from more than one place at one time.

Ben

[Jacobson-ni]

Are you able to attach any of the crash reports (the .zip files generated)?

[ChristopherPovey]

---

@bean123 wrote:

I would use the desktop execution trace toolkit (DETT)

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P9vgSAC&l=en-US

---

Will this work across versions? So if I build the executable in LabVIEW 2017 will the LabVIEW 2012 Desktop Execution Trace Toolkit monitor it?

I don't really want to contaminate the target set up with the LabVIEW 2017 development system.

Thanks.