LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

LabVIEW Access Violation Crashes

Hi Amezam, thanks for your reply.

 

We appear to be having different access violations each time (or they are one of a large group of them, we cannot tell).

 

The crashes appear to be at random, we cannot connect the crashes to any specific sequences of events and we cannot reprocude the crash consistently on the same piece of code! One pattern I have noticed, however, is that the violations appear to coincide with a peak in program activity - very frequent indicator updates for instance*.

 

I am unable to disable antivirus protection at will, but I will raise it with our IT Support to see if we can try that.

 

I believe that we are intearacting with external code - 3rd party device drivers which include packed libraries. I have no control over these and, furthermore, if I were to remove them the code would not be able to function at all. However, if you think it is a good idea I can attempt to create a separate piece of code which calls the same driver function very rapidly to see if that is the problem.

 

As for error handling - those nodes which use them only return error codes from the base 3rd party libraries, which according to the documentation only return custom error codes (these are not related to the error/crash that we are seeing). If you think it's still possible that they will return an Access Violaton error and crash, I will link them up.**

 

 

* - sidenote: I implemented a method of reducing the number of updates to a graph indicator (from several times a second to several times a minute) - this has reduced the problem significantly.

 

** sidenote 2: Some of the nodes which return custom errors are linked properly, and they are not returning errors; these ones are the most likely to return errors since they are called extremely frequently. I am not seeing anything except the documented custom error codes from them.

0 Kudos
Message 11 of 37
(4,380 Views)

Update: The crash is not due to a memory leak, nor is it being caused by the high speed TDMS write. I was able to track the crash down to Optical Flow Tracking VIs that I am using (vision pallete). I am in discussion with NI tech support over this issue right now to try and figure out how the Optical Flow VIs is causing the systems to crash every 1-2 days. After disabling this code, three separate deployment units have not crashed in over a week.

Chris Walker
Certified Labview Developer
0 Kudos
Message 12 of 37
(4,375 Views)

@amezam wrote:

Hello P Anand,

 

Please see the post I did earlier to Stoove. Please let us know if it solved by cleaning the PC.

 

Best Regards


Thanks. I am just trying to figure out because of which it happens, may be from the posts earlier we can try to narrow down what is the common thing between all the crashes. In my software I use the follwing
  • LabVIEW
  • Veristand
  • Teststand
  • Python Server

Hope we can solve it.

-----

The best solution is the one you find it by yourself
0 Kudos
Message 13 of 37
(4,381 Views)

An update to my error message situation;

 

After logging the error messages for several hours worth of operation, I have noticed that the "EIP" values show some correlations. However, I don't know what an EIP is or what they mean, so some help would be appreciated;

 

1) The EIP values often end in 2175 (eg "0x049F2175") - these correlate with *something* running in my program, but I cannot tell what.

 

2) The EIP values ending in CABB (eg "0x01B0CABB") correlate with trying to use the "Stop" VI or sending a stop signal to a WHILE loop, which will finish the execution of the program.

 

3) I am getting this type of error in the situation where I do not have my code open in LabVIEW, just the LabVIEW "Getting Started" panel - errors occur when I try to close this panel by clicking the cross.

 

Can anybody help with interpreting these error messages please?

0 Kudos
Message 14 of 37
(4,323 Views)

Hi Stoove,

 

Have you tried disabling anti-virus? I've seen many things about these kinds of exceptions with regards to anti-virus. Also, has this program ran flawlessly before or has it always been having these exeception errors?

Matt S.
Industrial Communications Product Support Engineer
National Instruments
0 Kudos
Message 15 of 37
(4,294 Views)

The program did previously run flawlessly.

 

Disabling the AV is our next step; we tried repairing, then we tried a clean reinstall - neither of these have solved the problem. I'll check back when we have an answer on the AV front.

 

Thanks for all the suggestions so far! =3

0 Kudos
Message 16 of 37
(4,287 Views)

Here's an update to the original issue that started this thread.  After sending the crash logs to NI, someone looked at them and was able to trace the issue to the LabVIEW 2011 release we were using.  I wasn't given the full details about the bug or the fix, but apparently there was a stability issue and it was corrected in LabVIEW 2012.  Yesterday I installed LabVIEW 2012 and after some limited testing it appears that the problem is resolved for our multi-threaded failure mode.  So, if you are seeing a similar issue, it might be fixed by upgrading to LabVIEW 2012.  Note also, that several people have posted in this thread where they see the same error message, but it could be the result of a different root cause (not multi threaded executions).

 

The migration to 2012 isn't a big deal for us since we don't have a big installed base, but I would be very upset if we did and they couldn't fix this with a patch to LV 2011.  I would also not be happy if we didn't have SSP and had to buy upgrades to our platforms because of an issue like this.

0 Kudos
Message 17 of 37
(4,252 Views)

Well that figures, as soon as we think the issue is gone, it reappears.  We ran for a day and a half with increased batch sizes and thought it was gone, but it just took a while to appear.  Preformance seems to be much better, but we're back at square 1.

0 Kudos
Message 18 of 37
(4,235 Views)

Hi John Morrissey,

 

Do you have a corrective action request number or a service number for these access violations so I can look up the interactions with R&D?  I’d like to take a look into this further.

Matt S.
Industrial Communications Product Support Engineer
National Instruments
0 Kudos
Message 19 of 37
(4,198 Views)

Hi Matt,

I'm posting any updates in this thread now:

http://forums.ni.com/t5/NI-TestStand/LabVIEW-Access-Violation-Crashes-from-TestStand/td-p/2004661/pa...

 

Al Billington contacted me about it and said I should work with him, so I closed down my support request.  There's a dump report in that thread also.

John

0 Kudos
Message 20 of 37
(4,192 Views)