Runnable code crashes LabVIEW on save or run

[Wise_Owl]

I have some code that I recently was forced to upgrade from LabVIEW 2009 to 2011 and found that when the code is runnable (no broken arrow) it crashes LabVIEW imediately when running or saving.  Converting to 2012 or 2010 does not solve this.  Only 2009 works.  However, if I uncheck the "Allow debugging" box in properties, the code can be saved and run.

Going back to 2009 is not an option as there is much shared code that is 2011 now.  Anyone got any ideas?

[Michael5000Watts]

Hi Wise_Owl,

When LabVIEW crashes, does it report an error? Also, does the crash occur after a certain action, or is it simply after running the VI? Sometime, even though it seems that the crash is immediate, a certain portion of the code completes before LabVIEW crashes. One option is to try highlight execution or breakpoints to find what part of the code causes the crash. This might help narrow down the cause of the issue.

[Wise_Owl]

LabVIEW creates a crash report, attached.  It does this~ 500ms after the save button is pressed, or ~500ms after the run button is pressed (before the code appears to begin to run).

Good thinking about the crash still at some point in the code.  I added breakpoints everywhere to stop before any code is run and get the same crash.  Given that this happens on Save, it would appear to caused by compilation of debuggable code...

Thanks,

Damian

[Michael5000Watts]

Unfortunately, the generic "Access Violation" error does not give us much clues as to what the underlying cause is. To confirm, does this happen everytime you save/run the code (with "Allow debugging" checked)? Or only some of the times?

Also, are you able to save other VIs, or do all VIs show the same behavior?

[Wise_Owl]

The crash always happens on run/save, but only the main vi.  I've not had a crash while saving any of the sub vi's.

[Michael5000Watts]

You might want to try copying all of the info (code, description, etc.) from the main VI, placing it in a new brand new VI, and try to save the new VI. This would remove any doubt that the file has been corrupted in some way or another.

[Wise_Owl]

Mike,

Good idea.  I opened the culprit's diagram.  Press CTRL+A and copied its contents to a new vi, e.g. I didn't get any extraneous panel decorations.  Saving caused the same crash.

Damian

[JÞB]

While they are fairly rare insane objects can occur and would cause just such a crash.

You can often find what the problem is using Heap-Peek

[Wise_Owl]

Heap Peek - never heard of it.  I got it working, but the only red objects are "SellList" and these yield nothing when I press "F" button baring a pleasant "ding" sound.  So, this doesn't appear to be caused by an insane object, unless it's this SellList.

[Jeff-P]

Wise_Owl,

Did you click the button to submit the crash report for crash that you attached a screenshot of earlier? I tried looking up the crash but didn't find it. If you recreate the crash, submit the crash report and post back with the crash id (preferably text as it is easier to copy it and make sure it is right) and I can take a look to see if there is any useful information in the crash report. 

Thanks,

Jeff Peacock 

Product Support Engineer | LabVIEW R&D | National Instruments