Crash LabVIEW

In the zip file are two vi's. The "Crash LabVIEW.vi" vi uses a subpanel to open the other vi "just a while loop.vi". When the stop button is pressed on "Crash LabVIEW.vi", it sends the data to the stop button on the "just a while loop.vi". It works fine, but read the comments in the "Crash LabVIEW.vi". It was a simple mistake, but still no error message, nothing, just LabVIEW disappearing off the screen and off the task manager... I guess you can't compare apples and oranges, even though LabVIEW will let you try.
Attachments:
Crash LabVIEW.zip ‏21 KB

Hi Dominick,
I was able to reproduce this crash. You are right in that LabVIEW shouldn't crash without an error. This was reported to R&D (# 101959) for further investigation. Thanks for the feedback.
Regards,
Stanley Hu
National Instruments
Applications Engineering
http://www.ni.com/support

Similar Messages

Save for previous version 8.5 to 8.2 generates code that crashes Labview (uses classes)

Hello,
I'm working on some java style interfaces for labview for hot swapping of instrumentation for design patterns. When I try to port this code, developed on Labview 8.5 back to labview 8.2, the code it generates crashes labview (both 8.5 and 8.2).
Included is a small snipet of the work that demonstrates this behavior.
It includes to classes:
untitledProject1 - the containing project (version 8.5)
FunctionGeneratorI - Similar to a Java style interface (A class with all Dynamic VI's with no useful functionality)
FunctionGenerator33220a - An intended implementation of Function generator (only a few functions implemented)
and a folder "labview8_2Distribution"
Which contains the port of the 8.5 code to 8.2.
To recreate the error:
A.
1. Open "labview8_2Distribution\Users\Laptop\Desktop\object\Untitled Project 1" (8.2 save)
2. Verify it crashes labview 8.5 and labview 8.2.
3. Watch labview crash?
B.
1. Open the "Untitled project 1" in the root directory. (Using labview 8.5)
2. Save the project as a labview 8.2 type.
3. Try to open the saved version with 8.5 and 8.2.
4. Watch labview crash?
Greg Sonnenfeld
Attachments:
error.zip ‏885 KB

Hello Karunya,
In regards to your questions:
>Can you post your code? Have you tested this by creating another project?
Do you have an xcontrols in your projects? Do you have typedefs? Do you
have a LVOOP constant on your block diagram? Are you also using Classes?
I cannot post the cost as it is way too big. Not really my code but a spaghetti code from a previous programmer. I think problems saving it to a previous version have to do with a few things:
1) Memory - I have 1 GB of RAM and I am running XP. I notice the available RAM dropping quickly as it is saving and then it blow up.
2) Long Filenames - The directory path of the original file is incorporated into the saved "previous version" of the code. While a good design, it does make the file/path a bit longer when saving
3) One of teh things it saves is the drivers and their menus. This is due to the drivers being in a subdirectory of the original code and not in the c:\program files\national instruments\labview 8.5\instr.lib directory. I saw this when I tried to save the file as an LLB.
4) If I work with smaller parts of the code without long paths, it saves fine.
There probably are xcontrols, definitely typedefs, no LVOOP's or Classes. Hope you can do something with all this. It just seems that converting to a later version of the code should be reversable. Thanks.
Michael

Passing control reference to subVI crashes labview

Hi,
using a image control (as indicator) provided by imaq Vision, I tried to pass the reference of the control to a subVI. On a computer it works and on a other (same labview version, same vision version, same os, same hardware and hardware drivers!), this crashes labview. I tried to close the control refnum at the end of the subVI, but that changed nothing to the issue. Now I use the reference as a global variable and it seems to work...nevertheless, I would like to understand what the issue and if I should remove any passing to subVI of control ref because this can potentially triggers an error. My correlated question is if this global passing is a "fake" workaround or have real chance of improving (this before going through the whole code for changing all passing of reference to subVI)
thanks a lot

Hi,
thank CoastalMaineBird for your answer
How do you know it's this issue which causes the crash?
When I remove this parameter from and the only property node in the subVi that write to it, I have no longer any problem. Moreover, to ensure that's really the "passing", and made a global variable containing the reference to this control and use my original SubVi that do access the control through its reference number
, and it works! In this last exemple, the only change is the way of transmitting the reference
What LabVIEW version?
8.0.1
up to date according Measurement & Automation update tool
Given that one computer works OK, and another crashes, I would say that
you are seeing the effect of something else, not the cause. If passing
a control ref via terminals was fatal, it would be fatal all the time.
You have some other sort of issue, perhaps timing of the different
machines triggers the bug, perhaps running out of memory, perhaps
LabVIEW is corrupted on one machine.... But I don't think changing all
your code to use globals would solve the real problem. Actually, saying that I wonder about problem of synchronisation. I know from Visual C++ that this kind of error happens if two process try to access the same control at the same time. This is typically an error changing from a computer to an other, and mutex or semaphore are the way to deal nicely with that. But does labview contains already such a securisation? If so, the global variable point on a single object and can "fell" the semaphore/mutex. But passing make a copy that will likely have two different semaphore/mutex but will point to a single control! Do someone know if I'm wrong in this idea or not?
Thanks

Auto cleanup crashes LabVIEW (and VI isn't even that large)

Hi,
I'm trying to cleanup a VI, and whenever I hit auto cleanup LabVIEW crashes and when retsrated it doesn't even say it previously crashed. I narrowed down the problem location to a for loop. The wierd thing is that I went through all the wires and objects within the loop and did auto cleanup on them but it doesn't crash. So why when I do it on all combined does it crash?
I wrote a comment in the loop that crashes to show which on it is.
I'm on Windows 7 LabVIEW 2010.0f2 32bit
I did see this posting http://digital.ni.com/public.nsf/allkb/599FB39777BDB12486257514005B7293, but even when doing it manually as suggested it still crashes.
Thanks,
Matt
Solved!
Go to Solution.
Attachments:
Score Videos temp.vi ‏126 KB

This crash corresponds to a known issue in LabVIEW (CAR #298911), which has been fixed in the forthcoming LabVIEW 2011 release. I have attached a copy of your cleaned up VI from 2011, saved for 2010. You might try to copy the block diagram into a new VI and see if that still crashes LabVIEW, but otherwise an upgrade to 2011 when it's available should clear up the problem. Hope that helps.
John B.
Embedded Networks R&D
National Instruments
Certified LabVIEW Developer
Attachments:
Score Videos temp-1.vi ‏104 KB

XYGraph Cursor legend bug instantly crashes LabView 2012

Hi!
I am just facing a very annoying bug.
Please find my example VI attached, I would like to know wheather you can confirm the bug? Run the VI if you wish to see some curve (actually the bug appears even if you do not put any data on the graph, if you do, just the same) and after that try to click on the cursor legend vertical scrollbar to scroll up or down to see the cursor names.
It instantly crashes my LabView 2012 Full version: 12.0.1f2 (32-bit). This XYGraph always crashes LabView... I cannot go on with my project, now I will just try to bypass the error, I will try to delete the cursors, and add them again...
Anyhow, very strange and annoying behaviour...
Anyone could repeat the same bug?
Thanks for support!
Solved!
Go to Solution.
Attachments:
XYGraph_bug_test1.vi ‏149 KB

hello,
please find attached my example VI, where I would like to programmatically set the label position of a cursor. Why my code does create at every run a new cursor with the same name?
thanks!
Attachments:
cursor_offset_label_via_propertynode.vi ‏12 KB

Internet Toolkit for G5.0 crashes Labview 8.2 during Mass Compile

I have just received my Labview 8.2 update and installed it my system along with all my toolkits. When I tried to Mass Compile Labview 8.2 directory I found that it would crash labview consistantly as shown in the attached image.
I traced this to the vi's supplied with the Internet Toolkit for G5.0.
The workaround is ...
1. Re-installed the Internet Toolkit for G5.0 into Labview 8.2
2. Mass Compiled ...\project\_config\authcfg.llb using Labview 8.0
3. Mass Compiled ...\project\_config\authcfg.llb using Labview 8.2
and there wasn't any more Labview 8.2 crashes during mass compile. As Labview 8.0 was able to mass compile the internet toolkit vi's without crashing I am suspicious that Labview 8.2 might not be completely compatible with Labview 5.0.
I posted this just in case anyone else sees a similiar issue.
David
Attachments:
Labview 8.2 Mass Compile Crash with Internet Toolkit.png ‏34 KB

David,
I was able to reproduce the crash mass compiling authcfg.llb or just trying to open the VI named 'Directory Configuration'. That code is saved in LabVIEW 5.0.1 and must have something that LabVIEW 8.2 chokes on, I'll have to get someone to investigate it. Your workaround of saving that .llb or even that one VI in 8.0 first (or probably even 7.x) is the only way I see around it with 8.2.
I do want to mention that in Q1 2004 we released version 6.0 of the Internet Toolkit and it does not exhibit this behavior. So the official solution for this crash is to upgrade to the latest Internet Toolkit.
Kennon

Simple Math VI crashes LabVIEW 2009 SP1

Hi,
We previously filed a related issue, (ref #: 7302858). The last problem was resolved by
Andy Hertzka from NI re-compiled the VI and send it back to us. That re-compilation solved the LabVIEW crashing.
However, the interesting crash happens again.
I attached a working VI before the change and a non working VI after the change and save. All the change I applied to the VI is
1. Add the "Word bits" as a connector on the diagram
2. Save it Then the VI begin to crash LabVIEW 2009 SP1.
Before the change, the VI was functioning all right.
Any idea why this might be happening? Can you try to recompile the non_working version and send it back to me for a try?
Thanks,
Tian
Attachments:
Non_working_AfterChange_RECOMPILED LRSample_U32in_U32output.vi ‏110 KB
Working_B4Change_RECOMPILED LRSample_U32in_U32output.vi ‏110 KB

Tian,
Like Andy I was unable to see why this code is unstable on your machine. I am able to run the code fine on my computer without any problems. Looking at the code on the block diagram I do not see any major "crash worthy" issues with it.
I have resaved the VIs like Andy had in order to fix your issue. By the way what OS are you using, windows 7? It might be helpful to save the log file for the LabVIEW crash. You should get this option when LabVIEW is restarted.
<Joel Khan | Applications Engineering | National Instruments | Rice University BSEE>
Attachments:
Non_working_AfterChange_RECOMPILED LRSample_U32in_U32output1.vi ‏108 KB
Working_B4Change_RECOMPILED LRSample_U32in_U32output1.vi ‏108 KB

Crash LabVIEW in one click

The buggiest LabVIEW ever (8.6.1f1) keeps on giving:
WARNING: will crash LabVIEW and you will lose any unsaved work.
Open the INFO CLUSTER ctl in the attached LLB (28kB).
(Yes, I know it's ugly, I'm trying to work on it)
Right-click on the table.
Watch LabVIEW die.
Arrrgh.
Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com
Blog for (mostly LabVIEW) programmers: Tips And Tricks
Attachments:
Crash-o-matic.llb ‏28 KB

Yes, I know about the overlap stuff.
Like I said, I was working on it and re-arranging stuff on the page when I discovered the bug.
Actually, I worked around it like this:
Copied the MCListBox to a blank VI.
Created a generic property node.
Linked the property node to the MCListBox.
Set the AUTOSIZE ROW height false
Set all the row heights to 23 instead of 25.
Pasted the copy in place of the original in the control I was working on.
That's what I wanted to do via dialogs, but crashed instead.
Thanks for your offer, though.
Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com
Blog for (mostly LabVIEW) programmers: Tips And Tricks

Bug: Windows 7 DLL call to turn off monitor message crashes LabVIEW 10.0f2

Hi,
I wanted to log this bug on the forum. I have already logged this with NI UK Support: CAR# 286873
I was trying to find a way to turn off a laptop lcd
monitor during measurements. I was trying to replicate this
http://codereflect.com/2009/04/03/how-to-programmatically-turn-onoff-your-monitor/
which uses windows messaging.
I found the attached Monitor-1.vi somewhere on the forum that seems to do the above.
However when I run the VI it crashes LabVIEW 10.f2 on Windows 7 32-bit.
cheers
David
Solved!
Go to Solution.
Attachments:
Monitor-1.vi ‏13 KB

Hi Cosmin,
That was it! Thank you so much!
I will let NI UK support that you identified the issue and get them to close the CAR.
cheers
David
Attachments:
Turn off Monitor.vi ‏12 KB

Spectrogram Graph Curser Crashes Labview

I was wondering if anybody else have this happen to them. I'm trying to set the location of the cursor on a spectrogram (intensity graph) (the x value), and it crashes Labview. I tried compiling to a .exe, and it still does the same on another computer.
Message Edited by d1sturbanc3 on 02-19-2009 11:33 AM
Message Edited by d1sturbanc3 on 02-19-2009 11:33 AM

what version of LV? what OS? can you post a subset of your code that demonstrates the problem?
Mike...
Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion
"... after all, He's not a tame lion..."
Be thinking ahead and mark your dance card for NI Week 2015 now: TS 6139 - Object Oriented First Steps

GetDefaultPrinters (WinAPI call) Crashes Labview

Hi all,
For several reasons I need to use the windows API to get the default printer. I know about labview's activex solutions but those are not universal.
See attached VI. This winapi call crashes labview rather consistently. It runs fine and returns correctly the default printer. However, some time later, a few seconds or a few operations later it will always crash labview. Why? I've tried changing it to "Run in UI thread" instead of any thread but neither seems to help...
To get it to crash immediately, try closing the VI. That seems to do it every time. Access violations...
Solved!
Go to Solution.
Attachments:
defaultprinters.vi ‏10 KB

No. You actually did NOT allocated memory in your VI.
Here is how to allocated memory, the old way:
George Zou
http://webspace.webring.com/people/og/gtoolbox

Search for text in main VI crashes labview

I'm using Labview 8.6 under Windows Vista Business. I'll update to Labview 2009 once I finish the current project. While working on the current project, when I do a text search in the main vi, the Labview environment crashes without error and without warning. When restart, it recovers any unsaved VIs, but the same problem occurs. Rebooting the PC doesn't help. If I go back far enough in my archives, I can get around this error, but I'll lose a week of work. Since there is no warning or error message, I don't have any way to trouble shoot the bug. I've looked under theLavVIEW Data/lvfailurelog folder, but no new log file is generated.

>It's possible it's an 8.6 bug, but it's also
possible you may have a corruption in your VI.
>Try forcing a recompile
by holding down the control key on your keyboard and pressing
>the run
button in the toolbar. You can also try posting the VI to see if anyone
else can reproduce the problem.
Thanks for the suggestion. Recompiling doesn't make any difference. If I open the Main.vi outside of my project, it has the same problem, so it must be within that VI.That VI uses a ton of classes and a number of customer control types, so I doubt that anyone could open just that VI without the rest. I know a local NI rep pretty well...I'll check with him on Monday.
I ran VI analyzer and found a number of items, none of which justifies crashing the Labview environment, particularlly without an error message. I can attempt to fix all of the items found, but I don't have any guarantee that it will fix the problem, since I don't know what is causing it in the first place. If this is a known issue, that would help to narrow down the fix.

Bind FPGA host reference to type definition in labVIEW 2012 crashes labVIEW

Hi,
I am using FPGA target device 5641R and labview FPGA 2012 with 5640R ver 1.7.
On the configure window of open FPGA VI reference function, choosing the dynmaic mode shows broken arrow when wired to the 5640R configuration VIs (i.e. Configure timebase, Configure ADC default, Configure ADC NCO functions). So i tried the other option which is binding the FPGA host reference to type definition and choose the control from path C:\Program Files\National Instruments\LabVIEW 2012\instr.lib\ni5640R\Configuration\NI-5640R VIs\ni5640R FPGA VI Reference.ctl. But after that when i try to save the VI on which open FPGA VI reference function is placed, labVIEW crashes. I am unable to figure out the reason. Earlier I was working with labVIEW 2011 and it was working fine there. Any suggestions would be highly appretiated.
Please see the attached images for more details.
Thanks
Attachments:
1.png ‏33 KB
2.png ‏71 KB
3.png ‏40 KB

Check out this thread. It looks like someone else ran into a similar issue and made changes that fixed their application.
http://forums.ni.com/t5/IF-RIO/correct-5640r-template-use-recommendation/td-p/1331918
Jeff B.
Applications Engineer
National Instruments

Crashing LabVIEW when calling SetDoubleClickTime (Windows UI API)

Hmm, I think I'm calling SetDoubleClickTime correctly through the Call Library Funciton Node. I'm even able to update the double click time. For some reason, though, LabVIEW crashes upon execution of the function.
I suspect that I'm not handling the returned Boolean value correctly, but I've tried returning all permutations of unsigned integer, 8 bit, 16 bit, and 32 bit. All result in crashes.
Any ideas?
Thanks,
Victor
Attachments:
SetDoubleClickTime Function.pdf ‏69 KB

Here is what your call should look like...
I suspect it is your calling conventions. They should be stdcall (winapi)
Attachments:
SetDoubleClicktime.vi ‏7 KB

Vision Builder Crashes Labview

I have an application where I need to acquire and inspect many high resolution images 3Mp at high throughput.
I'm using:
LabVIEW 8.5.1
NI-Imaq 4.1
Imaqdx 3.2
Vision Builder AI 3.6
ISG 3Mp Camera through Startech 1394a PCI card
In order to meet the cycle rate, I'm trying to multi-thread the application by having one thread that acquires images and enqueues them into another thread that saves them to the hard drive then runs the VBAI inspection. The VBAI inspection then uses the "simulate acquisition" step inorder to load the image from the hard drive and make the appropriate measurements. I've run the application and monitored the processor usage, and the processor seems to stay within 0-80%. However, my application will crash intermittantly.
I've been able to repeat the behavior pretty reliably if I activate/toggle a ring control on my front panel while the cycle is running, and I can't do so if the VBAI thread is not running.
I understand that this is could be a difficult problem to help debug remotely. I'm wondering if there is anyone with similar experience, or some better way for me to creat a high throughput machine vision app with VBAI.
Thanks,
Ryan

Dear Ryan,
You are right, this is difficult to debug remotely, but I can make a suggestion or two. Perhaps you've taken care of these, perhaps not...
One potential downfall with this setup is running into a race condition. If you don't establish data dependency, and make sure that you save and close a particular image before trying to open back up again with VBAI, you could cause the behavior described. Race conditions would be even more of a concern if you were using a certain number of files as an image buffer, and then recycling through them.
What in this ring control? What does the ring control do?
Have you tried generating LabVIEW code from your VBAI inspection, and then encapsulating the VBAI code in a subVI, and just passing your images into that instead of saving them to disk? I would suggest doing this to see if you still experienced the crashes when you are only working in LabVIEW, and without saving and opening images from disk.
Let me know how things go; I hope the above suggestions provide some help.
Best Regards,
~Nate

Crash LabVIEW

Similar Messages

Maybe you are looking for