Error: Access violation (0xC0000005) at EIP=0x00764624

[QFang]

Thanks.. I'll think about it, but I think we will try 2013  when we get a chance to cycle that in.

[QFang]

I figured it may be of interest to people on this thread that our crash is perfectly reproducible and traced to a damaged or corrupted .tdms_index file... deleting the .tdms_index file so that it gets re-created when opening the parent tdms file fixes the issue.

Based on the information in this thread, I would say it is likely that the index file incorrectly points to data-space that the actual tdms file does not occupy, thus triggering various security and safety measures in Windows and/or AV software since the "open tdms" function call then suddenly tries to access memory outside of the scope that it is supposed to run in.. .but this is pure speculation on my part.

[deppSu]

Hi QFang,

Can you upload the corrupted .tdms_index file and the tdms file? I think this issue worth fixing in TDMS Open.

[QFang]

deppSu,

You should be able to retrieve the files using NI service request 7390176.  Please note that ALL information contained in this file is confidential and not to be shared or republished to any open forum (such as this one). 

Also, for everyone else's benefit, CAR#: 427535 should be tracking this issue so keep an eye out for it!

Thanks,

-Q

[deppSu]

Good to see it is CARed, thanks.

[McTOM]

The same problem is caused in my case by "wait on asynchronous call". I attach a part of code that always causes LabVIEW to give this error, no matter if it is run in LabVIEW, or built into EXE.

The queue that can be seen on this picture is giving the called VI a signal to end its work (stop an infinite loop). I thought it might actually end the VI before the "wait on asynchronous call" is executed, hence making the reference point to the space where there is no running vi present anymore, but I introduced a significant delay and it seems this is not the case.

[McTOM]

It seems that I managed to solve this problem. Everything runs smoothly since I disabled "in-line subVI into calling VIs" in the VI that contained the code I mentioned above. I have no idea why would it make any change in this case.

[Vasilich2004]

In LabVIEW 2014 I met Access violation crash on "Call By Reference Node" function. It was perfectly stable in the most complicated application and doesn't show up in simpe test applications. So I created a ticket, sent some LabVIEW reports but NI support didn't RDP to debug.

[Jacobson-ni]

---

@Vasilich2004 wrote:

In LabVIEW 2014 I met Access violation crash on "Call By Reference Node" function. It was perfectly stable in the most complicated application and doesn't show up in simpe test applications. So I created a ticket, sent some LabVIEW reports but NI support didn't RDP to debug.

---

Is this something that we can help with on the forums?

[Hooovahh]

Okay I'm having some major crashing here and there are key words here that make my setup sound similar.  I'm using a subpanel with which opens VIs and inserts them.  I'm using the Start Asynchronous Call.  Attached is a minimized part of my application that seems to show the issue.  Open and run the .\Engines\Sequence Editor\Engine Core\Engine Core.vi.  Then when it is running go to the File >> Open and LabVIEW should crash with the access violation.  This is in 2018 f2 patch.  It happens to crash at an express VI but I've seen times when this crash happens just on running a VI, and in some cases on just opening it.  I tried replacing the browse express VI with the primitive, and that gets farther, but in the full application crashes are happening in this UI while doing stuff with the subpanel.