Locating the Origin of an Access Violation...

[bean123]

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.

---

I'm not sure if it will work across versions.  I can experiment with 2018->2012 but not the other way around (lower version DETT to higher version LabVIEW.

My understanding from your previous messages is that the crash is happening on the Desktop side (windows) so I don't see why you would need to contaminate the target system.  You would just have to build your desktop exe with debugging enabled and VI server ports enabled with local access (or remote if your DETT is on another machine).  No other changes to the target.

[ChristopherPovey]

As a follow up to this I rebuilt the application to support the Desktop Execution Trace Toolkit.

During the run the executable crashed. The toolkit didn't log the crash other than it lost contact with the exectable.

It did log two Reference Leaks. One of which is in my initialisation VI. The VI creates a FPGA reference which is stored in a global variable array. The other VI's in the executable use this reference. The executable was running for three and half hours before the "Reference Leak" warnings were reported.

My question is, when the DETT picked up the Reference Leaks, did LabVIEW do something about them, i.e. did it release them? If it did automatically release the leaky references? How can I stop LabVIEW doing that?

[Yamaeda]

Are you using a FGV or a 'real' global variable? I've heard of similar problems from colleages. In some project they added a simple 1 sec loop in a asynchronous VI that read the reference just to 'remind' LV that the ref was actually still used. The reference shouldn't be unloaded as long as the owning VI is alive, so do we know that's not the problem and this is the symptom?

/Y

[ChristopherPovey]

---

@Yamaeda wrote:

Are you using a FGV or a 'real' global variable? I've heard of similar problems from colleages. In some project they added a simple 1 sec loop in a asynchronous VI that read the reference just to 'remind' LV that the ref was actually still used. The reference shouldn't be unloaded as long as the owning VI is alive, so do we know that's not the problem and this is the symptom?

/Y

---

Real global variables. I created one for the FPGA VI Reference handles (because my software can handle multiple NI cards, but the bought in library handles cards on an individual bases. I pass the correct handle based on the selected card). The other global is in the 3rd party library which is a Data Value Reference. I have modified my code to release this global now after it has been finished with).

My executable is running a loop already which has a list of commands. These "commands" are VI names. A set of LabVIEW 2012 VI's call the commands in the executable which is built in and runs LabVIEW 2017 only code. It works via LocalHost TCP data transfer from the 2012 VI's and the 2017 VI's.

The 2012 code does have a keep alive thread VI which runs every 15 seconds. It calls the Server with a Dummy command. This stops the TCP timing out and releasing all the handles to the FPGA cards.

[ChristopherPovey]

In an attempt to stop the reference leak for, what I suspect is the FPGA VI References. My code now has a loop thread running. This loop asks the FPGA for its temperature. I don't do anything with it, but it forces the use of the FPGA VI References once a second.

However the DETT still reported a pair of unknown reference leaks, at the same time, in my Initialisation VI. Shorty afterwards the software reports:

"NI-RIO:  (Hex 0xFFFF0925) The handle for device communication is invalid or has been closed. Restart the application. [Error Code: -63195]"

I have not closed the handle (the 3rd party FPGA code I am using never closes the FPGA VI Reference handles. It is up to me to do it in my Close VI, which I have not called at this point). I am assuming it is related to the "Reference Leaks". The software has been running for 6 hours by this point. The software also has successfully made use of the FPGA VI Reference less than a second before the reference leaks occur.

This is getting annoying now... 😞