LabVIEW 8.6 Crash

I’m getting this message lately: “LabVIEW 8.6 Dev. Sys. has encountered a problem and needs to close. We are sorry for the inconvenience”. That is a crash and it happens at random: when a vi is running, when I edit the block diagram, when I stop a running vi or close the vi. Please advise.

Well, there are a lot of things that can cause LabVIEW to crash unexpectedly, some are actually LabVIEW, some are not. Did you add a call to a .dll or some non-National Instruments instrument, board or driver?
In the Windows environment LabVIEW will attempt to create a crash log in the directory ..\My Documents\LabVIEW Data\lvfailurelog called something like lvlog06-21-11-21-11-00.txt, which gives the date and time of the file. This directory will probably have a lot of these files if you have crashed a lot. In this file there may be more evidence of what LabVIEW didn't like. I say "may" as about a year ago I was fighting a similar problem that turned out to be a badly written USB driver .dll (wrapped by even worse LabVIEW code). The error logs weren't too useful in that instance.
Tell us anything that you can think of that has changed, look at the latest error log, post if if you can and it isn't too long (my biggest was 31K, most around 4K)
Putnam
Certified LabVIEW Developer
Senior Test Engineer
Currently using LV 6.1-LabVIEW 2012, RT8.5
LabVIEW Champion

Similar Messages

Labview 12.0 Crashes while trying to open a VI

Hi,
I've got a problem while opening a file. I did not have any problem opening it like five minutes ago. I tried to reboot the computer and shut down labview couple of times.
The labview 12.0 crashed and left me a message attached. And the problem VI is also attached.
Would you please help me with it?
Attachments:
Crash.PNG ‏21 KB
ClickToGo(RT).vi ‏71 KB

If you have a back up copy of the vi I would suggest going back to that. The vi and error message would indicate that you got what was refered to as an "insane" error, where LabVIEW lost track of some "connections" in the vi. This results in a corrupted vi which can't be loaded.
As was alluded to, a 1Mb+ size vi is pretty large, which, at least in the old days of LabVIEW, would increase the chances of getting "insane errors". If it is possibly to encapsulate some of the code in sub-vi's it might also help.
Sorry I can't fix the vi you had, most of us who have been using LabVIEW for a while have experienced this, good luck.
Putnam
Certified LabVIEW Developer
Senior Test Engineer
Currently using LV 6.1-LabVIEW 2012, RT8.5
LabVIEW Champion

Bug (LabVIEW 2011 sp1 crash)

Bug (LabVIEW 2011 sp1 crash)
1) Open LabVIEW
2) Blank VI
3) Front Panel / View / Class Browser
follow exactly this :
Class Browser / Object library ---> select "LabVIEW Classes" ---> and then clic "Search"
result : The window "Class Browser Search" opens ----> do nothing ... just "Cancel"
back to the window Class Browser ...
Class Browser / Object library ----> now select "DAQmx"
result : in the window Class Browser : Objet library = DAQmx
Class = DAQmx buffer
don't touch anything else (!)
and now clic "Search" ... LV CRASH

When you meet your colleagues, could you ask them, of course when they have time, to create this number.
This will make me happy, and this would be a small reward for this bug report.
Thank you very much in advance ThiCop

Labview Program always crashs after a few hour' work

My Labview Program always crashs after a few hour' work. The error report is:
#Date: 2014年7月30日 4:27:27
#OSName: Windows 7 Ultimate
#OSVers: 6.1
#OSBuild: 7600
#AppName:
#Version: 12.0 32-bit
#AppKind: AppLib
#AppModDate: 07/29/2014 20:13 GMT
#LabVIEW Base Address: 0x30000000
<DEBUG_OUTPUT>
2014/7/30 8:34:11.006
DAbort 0xF50EFD7B:
c:\builds\penguin\labview\components\mgcore\trunk\12.0\source\MemoryManager.cpp(1104) : DAbort 0xF50EFD7B:
minidump id: 6ebe0400-78d2-41e3-b2fd-858c21e3567b
$Id: //labview/components/mgcore/trunk/12.0/source/MemoryManager.cpp#13 $
</DEBUG_OUTPUT>
0x30076B23 - lvrt <unknown> + 0
0x307D1F90 - lvrt <unknown> + 0
0x30605C66 - lvrt <unknown> + 0
0x6C42A045 - nivissvc <unknown> + 0
0x075A1F00 - nivision <unknown> + 0
0x03B0577A - <unknown> <unknown> + 0
0xE5BA0800 - <unknown> <unknown> + 0
Who knows what had happened? Thank you for your help.

Thank you for your reply.
I don't build array continuously. I just build a few queues. I am sorry the program is too large to show it to you. I have read the dump file. It seems like memory overflow. Do you think so? But it seems like there is no chance for memory overflow in Labview. The dump file is as below:
Microsoft (R) Windows Debugger Version 6.3.9600.17029 X86
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [D:\LabVIEW Data\LVInternalReports\1.0.0.1\51437f73-aab6-4097-b7e1-3fee8a74e4dd\6ebe0400-78d2-41e3-b2fd-858c21e3567b.dmp]
User Mini Dump File: Only registers, stack and portions of memory are available
************* Symbol Path validation summary **************
Response Time (ms) Location
OK C:\Program Files (x86)\Symbols
Symbol search path is: C:\Program Files (x86)\Symbols
Executable search path is:
Windows 7 Version 7600 MP (4 procs) Free x86 compatible
Product: WinNt, suite: SingleUserTS
Machine Name:
Debug session time: Wed Jul 30 08:34:10.000 2014 (UTC + 8:00)
System Uptime: not available
Process Uptime: 0 days 4:06:44.000
This dump file has an exception of interest stored in it.
The stored exception information can be accessed via .ecxr.
(dfc.4b8): Unknown exception - code 00000002 (first/second chance not available)
*** WARNING: Unable to verify timestamp for ntdll.dll
*** ERROR: Module load completed but symbols could not be loaded for ntdll.dll
*** WARNING: Unable to verify timestamp for kernel32.dll
*** ERROR: Module load completed but symbols could not be loaded for kernel32.dll
eax=13dbec20 ebx=13dbe550 ecx=00000008 edx=00000008 esi=00000003 edi=13dbe570
eip=77b564f4 esp=13dbe500 ebp=13dbe59c iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246
ntdll+0x464f4:
77b564f4 c3 ret

LabView 8.5 crashes when opening this VI

I had LabView crashing the first time as I was saving this (sub) VI. Since, LabView will always crash when I try to open it. The funny part is that the code itself is still executed correctly when called by another VI. Just editing is not possible anymore ...
Any help to recover this file or to stop LabView from crashing is highly appreciated.
Thanx all,
Robert
Attachments:
SubVi_scan_CSV.vi ‏109 KB

Thank you for your replies!
It could be missing this VI - I wonder how you can tell? I cannot even open it, LabView will crash before. Unfortunately I dont have a copy of this VI, its about 2-3 days brains in it ...
I am not so sure how do use the VI server. I am not soo experienced yet, but I will look into it.
I tried adding the VI as a subvi to a new VI, but LabView will still crash. There is not error message at all, it just goes bye bye, completely ...
Message Edited by hempi23 on 02-05-2008 08:59 AM
Attachments:
SubVi_csv2array.vi ‏18 KB

Error 404 causes Labview 2010 to crash but only occasionally

Hello,
I am requesting help to solve a problem with LabVIEW 2010 crashing. I am new to this company and the last Labview developer left without providing
background on this problem. Labview crashes after running project VIs. Labview closes without warning or error messages. The project acquires data from pressure transducers, dP transducers, thermocouples, IEPE, load cells, and voltages through NI real-time system and has digital I/O. NI hardware includes PXI-1050 with modules 6221, 6280, 6224, 6220 and NI PXI-1052, SCXI-1306, SCXI-1112, SCXI-1520, and SCXI-1102. I've reviewed the labview program and the software relies heavily on shared variables, references, and local variables but I cannot find anything that stands out as a problem in the software .
The program crashed again today after running for only 1/2 hour and was not recording data. No error message occurred before the crash and the only error after restarting LabVIEW was the standard message that LabVIEW did not close properly. I went to the Event Viewer and at the time of the crash I received the following information:
Event ID = 3299
Source = LabVIEW
Log = Application
Level = Error
LabVIEW Information: Error 404 "Not found" for "/national instruments/ real-time execution trace toolkit/ 2.0/ trace receiveport", file "Crogram files (x86)/ national instruments /shared/ ni webserver/ www/ national instruments/ real-time execution trace toolkit/ 2.0/ trace receiveport": Can't access URL
According to Event Viewer, this error 3299 occurred 15 times in the last 3 days. LabVIEW crashed today at 10:19 am at the same time this error 3299 occurred but LabVIEW did not crash the other times this error occurred in the last 3 days. I believe this error is related to the crash but does not usually cause the crash. It appears to me from reading the error message that the error is the result of occasional lose of communication with the real-time system (Can't find URL). Any suggestions how to resolve this would be greatly appreciated.
Bill

1. Have you had this code working before on this or another machine?
2. Which operating system and version of LabVIEW are you running? (This can be found in Control Panel >> All Control Panel Items >> System)
3. Which National Instruments Drivers are you using? (This can be found in the measurement an automation explorer under the software tab [a screenshot would be good])
I would look into removing afsetup.exe which is a data collection tool provided by Microsoft which could a) not be installed correctly and/or b) trying to pull data from LabVIEW. I think this may help you out, as even though your programs aren't explicitly calling it, the service is running in the background.
Secondly, I would look into stopping the NI Web Server application that could be polling a web page that's not needed.

How can I diagnose a Labview RT program crash on cRIO 9073?

I have 2 cRIO 9073 purchased about 1 year apart. Both are running the same realtime application. The first cRIO runs fine. The 2nd cRIO crashes intermittently while executing 1 particular VI that contains 2 timed loops running in parallel (1 collecting data and the other controlling machine movement). When it crashes, the app stops, web server and FTP stop responding, MAX cannot communicate with the device ( I must perform a hard reset). After reset, viewing the error log using MAX shows no errors. I've added message logging to see if it stops in a particular place, but see no patterns. In some cases, the device seems to be continually restarting (every 2-3 minutes) until it finally hangs. In many instances, my configurations files (used to store runtime variables) have been corrupted or erased. When trying to deploy the app on this Rio, I generally must try multiple times because I receive the error, "Error deploying on target". I have tried formatting the flash and reinstalling the OS many times from different sources.
I'm running Labview 2009, SP1 with the FPGA option.
Any ideas on how to diagnose this problem? Are there any diagnostic tools to test this device?

Here's a better description of what I'm trying to do. This system is used to control the head position on a test machine. I used the LV RT wizard to create the base VI with 1 deterministic loop and 1 non-deterministic. The deterministic loop schedules 2 different test. Test 1 is every 5 minutes (collect analog data, read temperatures, calculate new head position based on temperature , drive stepper motors to new position, collect data after moving, then dismiss). Test 2 runs once a day with a duration of about 4.5 hours (drive stepper motors to user defined position, simulatiously collect data at various rates from 5Hz to .01 Hz, drive head to next user defined position, etc). This test has 2 timed loops running at different rates, one collects data, the other moves the head and acts as a timer to know when to move to the next position.
If I never run test 2, then the system has never crashed, leading me to believe the problem is in the test 2 VI. The crashes don't necessarly occur in the Test 2 VI. On some occations 1-2 hours after Test 2 has completed, the CRIO will start rebooting itself (every 2-3 minutes). This may happen 4-5 times until it will finally hang completely.
Since the crashes happen randomly (it may run for 2-3 days before crashing) I'm trying to find some way of trapping errors or exceptions that would give me some clue as to what the problem may be.

LabVIEW 64-bit crashes upon startup but LabVIEW 32-bit works fine.

Recently had to uninstall and reinstall both LabVIEW 32 and 64-bit versions because the network administrator is dumb. Now 32-bit works fine but the 64-bit version immediately crashes upon opening. Getting the following Labview Crash: Exception: Unknown (0xC06D007E) at EIP=0x000007FEFCE1940D. We're running LabVIEW 2012 on Windows 7 64 bit system.

Did you try to repair the 64-bit version? Was it working previously fine?
The best solution is the one you find it by yourself

Labview 8.20 Crash using vi's created with import dll wizard

Has anyone had issues with the DLL wizard or DLLs that use the USB port?
I have used the DLL import wizard to create an instrument driver for a picoscope 3424. When I run the Initaization.vi it exicutes properly, however, if I close the vi I get the Labview must be closed, send an error report to Microsoft blah,blah. If I disconnect the PicoScope (unplug the usb cable) then close the VI no error happens.
Once I received the Labview invstigate error and sent the data to NI (REF#7134654).
I had a driver written with LV 7.1.1 that worked with out any issue, I converted the 7.1.1 vi's to 8.20 and I no longer have the issue. This leads me to beleive that there may be a bug in the DLL wizard.
Andrew Alford
Production Test Engineering Technologist
Sustainable Energy Technologies
www.sustainableenergy.com

I'll try to answer your questions.
a) Yes that is correct, the source files are avaliable for download at http://www.picotech.com/software.html.
b) I have found some issues with the available settings in the DLL Import wizard, one is there is no availble choice for setting the parameter type to array. This is available when you right click on the CLN and select configure. I checked the configurations of the open unit and close unit nodes and they look the same. I have also noticed that the block diagrams created with the DLL Import wizard are very messy with overlaping wires and poor wire routing.
c) The original wrapper I created was done quickly and I only created the functions I needed at the time, I was attempting to create a proper Insturment Driver project and wanted all of the functions to be created, this is why I was using the import wizard.
I am still at a loss as to why disconnecting the instrument from the USB port prevents this crash from happening.
For now I have reverted to the 7.1.1 wrapper converted to 8.20 as I do not have time to continue investigating this issue.
Thank you for your response.
Andrew Alford
Production Test Engineering Technologist
Sustainable Energy Technologies
www.sustainableenergy.com

Labview logging program crash windows after 2 days

I am using Labview 8.0, and running the executable the program. What this program does is that it acquires data and then writes to hard drive. Each set of data is small but it writes also every second. It will create a new file every day so the file does not get too big.
After 2~3 days running, it crash windows. I think it somehow used up all the resource so the windows would not even response any more. And we need to run this program continually for at least one month.
So is this a memory leak problem of the executable program generated by Labview app builder? or could that be Labview does not release memory after it writes data to the file, and eventually used up the resource?
any suggestions?
Thanks

It is on a laptop with win xp, 1GB Ram. each data is only 40~50 bytes. The concatenate strings does not duplicate in memory, right? what about build path and open file? Do I need to close the file inside the loop? It is a very small program so I attached a screen capture here.
I am going to let it restart again and check memory usage tomorrow.
Thanks,
Attachments:
screen shot.gif ‏36 KB

LabVIEW Application Builder Crash : ntdll.dll faulting module

Hello guys,
I'm currently experiencing problems while building my project (LV2012 (32 bits) , Windows 7). At the very end of application build, LabVIEW crashes with no explanation (Screenshot in french, sorry)
Windows error logging follows :
Event 1000 Application Error
Faulting application name LabVIEW.exe, version : 12.0.0.4024, time stamp : 0x4fea600e
Faulting module name : ntdll.dll, version : 6.1.7601.17725, time stamp : 0x4ec49b8f
Exception code : 0xc0000374
Fault offset : 0x000ce6c3
Faulting process id : 0x16fc
Faulting application start time : 0x01cda5350f41f87c
Faulting application path : C:\Program Files (x86)\National Instruments\LabVIEW 2012\LabVIEW.exe
Faulting module path: C:\Windows\SysWOW64\ntdll.dll
Report Id : 8e5b1344-1128-11e2-97d8-c0f8dae81bad
I had the same problem on LabVIEW 2011. I tried to build my application with another computer (also LV2012 32 bits and Windows 7 64 bits) and I do not have any error.
What is wrong with my computer?
For french people, topic in french
Thank you for your help,
Regards,
Quentin
Solved!
Go to Solution.

Solution found :
-Uninstall all NI products
-Clear registry keys related to LabVIEW
-Delete National Instruments directory into Application Data
-Reinstall LabVIEW

Quit LabVIEW function generates crash report in executable

Hello,
I am using the Quit labVIEW to close down an application when the VI is built into executable. If stop LabVIEW is used the application just stops and leaves the window open. When the Quit LabVIEW function is used in an executable the application closes down completely.
In the current app I am developing (Windows 7 - LV2014SP1) I have isolated the Quit LabVIEW function as the source of the Crash Report I am receiving after I exit the application. I inpsected the crash report and there was mention of a thread that did not have appropriate access. So I ran the same executable with Adminstrator privledge and the error went away. It appears the application I am developing does not have sufficient privledge to close itself down and this is generating the Crash Report.
I have used the Quit LabVIEW function for many applications in the past without issue. I have not confirmed yet whether the problem is specfic to the current application I am developing or to LV2014SP!.
thanks for any help with resolving this issue,
- Troy
Solved!
Go to Solution.

TroyR wrote:
Wasn't there previously some issue with using Invoke Node in executables?
Not that I am aware of. But here is my trick for shutting down an application. I put the FrontPanel Close method inside of a Conditional Diagram Disable. The invoke node only goes into the RunTime Engine == True case. This way, the front panel is not closed if you are in the development environment.
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines

LabVIEW 7.0 Crashes when inserting "Instrument I/O Assistant" Express VI

Hi,
I'm unable to work with Instrument IO Assistant when ever i try to place the IIOA express vi on the blockdiagram a message pops up saying "MAX or IIOA is not installed correctly please install from NI driver CD". Also i've not installed NI-DAQ/mx on my PC.
I tried to install from IIOA.msi but the problem remained & also tried install/uninstalling MAX & IIOA many times but didn't work.At present i don't have Driver CD as well.
Plz help me out.
Thanks
sayaf

Sayaf,
Do you just get this message about IIOA not being installed correctly? Or does LabVIEW actually crash as the title of your post suggests? At what point does LabVIEW crash?
As far as the message goes, there are a couple of things to check:
1) Look under \vi.lib\ - is there a directory there titled "InstrIOAsst" with IIOA.LLB inside the directory? If this file is not there, then this is the source of the message you are receiving - I can help you get this straightened out if this is the problem.
2) If that file is present, then check your \Shared\ - is there a "LabVIEW Broker" directory there? If so, confirm there are two files present in that directory: LVBroker.dll and LVBrokerAux70.dll. If these files are not present then this could cause that message to show up as well.
-Tommy

LabView 6.1 crashes now and then when I try to get rid of an accidential starting connection when using the wiring tool.

Sometimes when using my labtop it happens that I get unwanted connections when using the wiring tool because my labtop notices mouse clicks that never happend. Usually you can get rid of those connections by pressing ESC. But unfortunately now and than LabView crashes completely when pressing ESC to get rid of the connection.
How can I stop LabView from crashing in that case?
Thanks for anybodies help!

Yes, I see this problem on both my LabView-Computers but more often on the labtop because of the strange integrated mouse.
Yes, I get an error message but I can't really translate it in english. It says something about memory access to a special address.
I might try reinstalling LabView one day if I have the time. I don't want to try LabView 7.0. I'm afraid it would be great. Unfortunately my boss alreday told me, we don't have money for the new version.
Thanks for your help!

LabView 7.0 crashes (intermittently) when launching VI

LabVIEW is crashing a _lot_ on a dual-processor machine running NT4 SP6. The error we get is:
"The error at "0x00c01e0e" referenced memory at "0x38345920". The memory could not be "read"."
It will crash when loading a VI, running a VI, or even when loading help for a module. It is frequent, but not necessarily reproducible (e.g. we can't do it at will). But it happens about every 30 minutes, at least. We _are_ linking into external DLLs that we developed ourselves in MSVC++.
We have uninstalled LabVIEW, reinstalled LabVIEW, updated to IE6 SP1, and uninstalled NI-Device.
We have Microsoft VC++ 6 SP5 installed, but we've uninstalled most other things that aren't strictly necessary for us to do our work.
Are there any known incompatibilities with LabVIEW 7.0 and our system?

TheWaterbug wrote:
> We have a function, GetOutputMsg(), that we export so that other apps
> (e.g. LabVIEW) can read a response from our DLL:
>
> void GetOutputMsg(char *pMsg, int nMaxBytes);
>
> LabVIEW needs to pass in a string pointer and an int so that our DLL
> knows how big a message it write to the string. Currently, we are
> using the Call Library Function module, and using a C String Pointer
> for arg1 and an int for arg2.
I do this usually by initializing an array "Initialize Array" of U8
integers of the desired size and then wiring it through the "Byte Array
to String" conversion function. Just watch out, sometimes badly
programmed C functions expect the buffer to be one char longer than the
maxBytes value indicates, for the strin
g terminating NULL char.
> How do we allocate a known amount of memory for a string in LabVIEW?
> Alternatively, if we just create a string in LabVIEW, how much space
> does it allocate, by default?
Aside from some internal space for LabVIEWs own string type it basically
allocates as many bytes for the string as there are characters in there.
This means an empty string is a pointer to an array of 0 bytes for the
underlying C function (and will certainly cause problems if the function
tries to do anything with that pointer).
Rolf Kalbermatter
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

Has anyone experienced Labview 8.2 crashing when attempting wire a cluster filled with object and task references?

I am getting a complete shutdown (crash) of Labview 8.2 when placing the wiring tool over a cluster that is filled with task and object references. The crash occurs on all computers I have attempted it on and happens throughout all VIs in all classes that distribute multiple references throughout the VI using a cluster. The entire project I am developing is programmed in GOOP. Has anyone experienced anything like this? I have provided a screen shot of the place where the crash is generated. Let me know if anyone has any insights.
B
Attachments:
LV screenshot.JPG ‏156 KB

There are several known crashes with LVClasses. One of the easiest
fixes is to load your application into memory and then hit
ctrl+shift+click on the Run arrow of your top-level VI. Then do
File>>Save All. You might also try selecting that wire (with the
selection tool -- use the Tools Palette to explicitly select a tool
other than wiring) and deleting it and then rewiring those terminals.

LabVIEW 8.6 Crash

Similar Messages

Maybe you are looking for