Error TheEvent.cpp line 233

[SMeserve]

Hi Carl,

I really can't release information publicly on this or any other CAR number.  However, you can look for this CAR number in future releases of LabVIEW to see if the issue has been resolved.  Again, if you have any information on making the issue more reliably reproducible, that is appreciated.

[carl_s]

Understood -- I guess there aren't any suggested work-arounds then?

I believe I'm only seeing this when I have TestStand configured to use the LabVIEW runtime engine, and not the development adaptor -- if that helps. 

[Mac671]

I do not know if this is exactly the same thing. But since it happens 3 code lines later I would asume that is possible.

I got this while using LabVIEW 2010 and I am getting this one quite often...

Musks thanks for the threads you've posted, I unfortunately did not have time to read through them. :(.

I do appriciate the effort though!

Question for NI, any idea or possible solution on this?

The PC I'm running on and I keep getting the error is a PXIe-8133 controller.

Which has the OS installed as it came.

Contents of the logfile I got after accepting to investigate the issue form the pop up window in the attachement.

####
#Date: 06 Sep 2010 09:29:37
#OSName: Microsoft Windows XP Service Pack 3
#OSVers: 5.1
#OSBuild: 2600
#AppName: LabVIEW
#Version: 10.0 32-bit
#AppKind: FDS
#AppModDate: 06/25/2010 12:14 GMT
#LabVIEW Base Address: 0x00400000

06/09/2010 10:27:51.232
c:\builds\penguin\labview\components\mgcore\trunk\10.0\source\ThEvent.cpp(236) : DAbort:
$Id: //labview/components/mgcore/trunk/10.0/source/ThEvent.cpp#3 $
0x01A864DE - LabVIEW <unknown> + 0
0x015D8E4B - LabVIEW <unknown> + 0
0x0045B37B - LabVIEW <unknown> + 0
0x0045B8CE - LabVIEW <unknown> + 0
0x0044651C - LabVIEW <unknown> + 0
0x015DAB37 - LabVIEW <unknown> + 0
0x015DAC88 - LabVIEW <unknown> + 0
0x00AF6B11 - LabVIEW <unknown> + 0
0x00AF7AF6 - LabVIEW <unknown> + 0
0x01AE5247 - LabVIEW <unknown> + 0
0x00445246 - LabVIEW <unknown> + 0
0x00444E31 - LabVIEW <unknown> + 0
0x004450CA - LabVIEW <unknown> + 0
0x00445197 - LabVIEW <unknown> + 0
0x01CF7DBB - LabVIEW <unknown> + 0
0x7C817077 - kernel32 <unknown> + 0
0x00000000 - LabVIEW <unknown> + 0

[Mac671]

Regarding the replication of this error.

I seem to be getting it when I select the File->Exit option from the LabVIEW menu in conjunction with selecting Don't save all when prompted to save changes in the VI's that have been opened.

As a side note (this might not be relevant to the issue)

This is abit of a pain becaouse I do have VI's that have been created in 8.5.1 ... whenever they get loaded to my LV 2010 program they are converted to 2010 compliant in the memory, and even though I do not make changes in them LV Wants to save them ... This is not good as I have other applications that rely on the version of those VI's to be 8.5 ( the're part of a LVLIB... ).

Anyway... hope this will help out in any way to replicate the issue.

[RavensFan]

---

@Mac671 wrote:

As a side note (this might not be relevant to the issue)

This is abit of a pain becaouse I do have VI's that have been created in 8.5.1 ... whenever they get loaded to my LV 2010 program they are converted to 2010 compliant in the memory, and even though I do not make changes in them LV Wants to save them ... This is not good as I have other applications that rely on the version of those VI's to be 8.5 ( the're part of a LVLIB... ).

---

That is normal LabVIEW behavior.  The VI's are changed because they are recompiled from 8.5.1 to LV 2010, thus it asks if you want to save them.

If you want to maintain your VI's in LV 8.5.1 as well, your best option is to make a copy of the library that you upgrade to LV 2010 and leave a copy of your library in 8.5.1.  Get your LV 2010 appliaction to point to the LV 2010 version of the library.

[Mac671]

Ravens Fan Thank you for the tip. I understand that behavior of LV 2010, I'm not going to expand why using a copy is not the best option for me in my case as it'll just get off topic.

The reason I've mentioned this is I see the error when I select Don't save all, I tought that the error in TheEvent.cpp might actually be caused by the fact my 8.5.1 VI are converted in Memory when I open them in LV 2010, and than later on when I try to exit LabVIEW and not save them, something terrible happens in line 236 of TheEvent.cpp.

But maybe this is a false lead...

Thanks,

Maciej

[Broken_Arrow]

On LabVIEW 10.0, I'm getting the error ThEvent line 236 quite often when closing LabVIEW regardless of what I do, saving or otherwise.

[Mac671]

Yes saving or not... seems to have no difference. I was wrong in the above posts. But I still keep getting this one.

[charris]

BrokenArrow:

Do you have error log files for the events? If so, your best bet is to submit a report when the issue occurs (if you haven't already). If you can get a consistent cause for the error (i.e. make it somewhat reproducible), put that in the comments of the bug report. That will probably be your best bet for getting the issue to R&D and troubleshooting the problem.

Maciej:

If you have a deployment system running 8.5.1, it may be a good idea to maintain the same version on both computers. As you've discovered, when you open the VIs in a later version, it brings the file versions up to match the software version you're running. Porting files between versions on a regular basis isn't really something that LabVIEW is designed for, and since you doubtless have good reasons for not maintaining separate copies, you could probably save yourself a decent bit of trouble by running one version. (That is, of course, making the assumption that running 8.5.1 is feasible on the second machine)

Is there a particular VI or limited set of VIs/subVIs that consistently cause the crash when you close the program? If possible, we'd need to isolate it down to see if it's a particular VI that causes the problem.

[Mac671]

What I've done is I've done some work and I've saved all the 8.5.1 vi's as LV10 VI's. To run everything on LV10.

I still keep getting the error when I exit LabVIEW.

If I manage to isolate the VI causing the problem I will come back with more info here.

Maciej