Labview Application Error

Hi,
A while ago, I tried to change the build-in AI read from NIDAQ6.9.1. On way or the other, the build in AI read was replaced by My AI read, which in fact was exactly the same as AI read. Because of problems when transporting the file to other PC's, I tried to fix this. That is where everything started to go wrong.
When I save a file, I cannot reopen it: "labview application error" while opening. When I click OK, it sometimes adds something like "cannot find all necessary files or llbs". The funny thing is that exactly the same file, but saved on an other PC works fine.
I then reinstalled everything containing the word labview or ni daq, but still the same problem: every file saved on my PC does not open anymore. Sometimes,
let's say one out of 25, the file opens, but then craches closing.
Can somebody help?
Thank you.

> Checking the disk did not help, and because I did not know what to
> look for, I have done a fresh install of my system, complete with
> formatting and so on. The problem is now reduced to the larger files.
> The small files do not crash if I save them immediately after opening
> them. With the larger files, there is not always a problem, sometimes
> I can manipulate them for over 20 times, and then suddenly, crash and
> no way to open them anymore.
> When I speak about larger files, this is something between 700kB and
> 980kB. Is this maybe to big for Labview to handle? I have 256 MB RAM
> on my computer.
There is no size limit. The limit is probably something like two
gigabytes or so. I have customer VIs on my computer that are fo
ur or
five MB.
You say that it crashes. It would be helpful if you could be more
specific. Is there a dialog? What does it say? If the dialog is a
Failure dialog, then LV also creates a LabVIEW Failure.txt file that you
can file with technical support along with a description and this will
help to track down the problem.
Greg McKaskle

Similar Messages

LabVIEW Application Error: The instruction at address x referenced memory at address y. The memory could not be written.

When trying to open LabVIEW, I get the following message, "LabVIEW Application Error: The instruction at address x referenced memory at address y. The memory could not be written." I've disabled the startup services, clean boot or diagnostics startup, but I still get the message. Any ideas as to why and how I fix it? It seems to work fine on other machines.

The standrd next step is to
Start Control panels >>> add remove programs >>> NI ....
Select the repair option then stand by to feed the disks.
Ben
Ben Rayner
I am currently active on.. MainStream Preppers
Rayner's Ridge is under construction

Using LabVIEW 6.0.1 in Win2K, I get the Application Error: The instruction at "0x004be060" referenced memory at "0x00000001". The memory could not be "read".

I have several VIs that use the same typedef. This "super" typedef consists of of a cluster containing 6 arrays. Each array has elements that are themselves typedefs. The array element typedefs consist of a cluster of strings, a string array, and yet another cluster typedef of instrument handles. The total number of unique typedefs is 13 (1 super, 1 as the array element in the 6 arrays, and 1 in each array element).
When I make any changes to any of these typedefs and I try to open a VI that uses the "super" typedef, LabVIEW stops loading subVIs and crashes with the Application Error: Application Error: The inst
ruction at "0x004be060" referenced memory at "0x00000001". The memory could not be "read". Also note that this VI contains several subVIs that use this "super" typedef for terminal inputs and outputs.
What is causing this problem? My only solution to this is to rename the "super" typedef, open the VI, ignoring the load of the "super" typedef, and once the VI opens (with a broken arrow) relinking the VI to the typdef after renaming the typedef back to the original name. This becomes quite painful when you have to do this for each and every VI that uses this typedef on every revision of the typedef.

You might want to first install the 6.0.2 patch before digging too far into this. You can download it from the ftp site:
ftp://ftp.ni.com/support/labview/windows/updates/6.0.2/
If the problem remains, then it is likely related to a few known issues with strict type defs. Unfortunately, there is not much that can be done about it at the present time. You might try having the *.ctl file open in the editor when you open the VIs to see if that helps.

Labview.exe - Application Error

While running VI in Labview 7.1, I receive the following error:
Labview.exe - Application error
The instruction at "0x05791a4b" referenced memory at "0x00000034". The memory could not be "written".
Has anyone seen this error? Does anyone have an idea of the cause?
For reference, this is a new computer, XP Pro, 4G ram. I did not get the error on the previous computer running the same code, but the old computer had other issues that required it be replaced.

This looks like an error popup from windows. Those hex values are going to be different depending on where the problem is in memory, and that could be different every time. It might have created a Dr Watson's error report, but that usually isn't enough to determine the cause.
I agree with John's direction -- is it reproducible? Is it only one VI?
Do you ever get another type of error message from LabVIEW? If fatal, it will appear when the error occurs. If a warning, it will appear at LabVIEW's next start-up. Please refer to:
KB 2PBCSFDW: Where Are LabVIEW Error Log Files Saved?
Trey B
Applications Engineering
National Instruments
Message Edited by Trey B on 10-24-2007 09:55 AM

Application Error: "The memory could not be 'read'."

I am programming an application in C#.
I am using an Acrobat Reader control on my form to display PDFs within my program.
I have tried a couple of different configurations with the form control. I have drag-and-dropped the control prior to runtime. I have also tried to add the control dynamically.
When I run the program, then activate the control and close the form, I get the following error.
"sw:name.exe - Application Error; The instruction at "0x0700609c" referenced memory at "0x00000014". The memory could not be 'read'. Click on OK to terminate the program."
I have googled this error for hours now, and cannot find anything that truly explains this error and how to fix it.
Thank you for any help.

To who may be interested, I managed to find a workaround for this bug in Adobe Reader 9.0.
It seems that, somehow, LabVIEW, and other programming tools, straggle with this version of Adobe (I assume that this is due to this bug) when closing the reference to Adobe created by the ActiveX container. So the solution would be closing "by hand" this reference, and telling Windows to free all the relation between the application (LabVIEW for us) and Adobe. The idea is that when we've done with the VI which displays the PDF via ActiveX, we should close the reference to the ActiveX control, close the reference to the VI, and:
- process all the Windows messages currently in the message queue (.NET: System.Windows.Form.Application -> DoEvents
- run CoFreeUnusedLibraries in "ole32.dll"
I hope this information can help somebody, as I wasted too much time to figure this out (finding eventually the answer in a forum of Adobe!)
P.S. For those who program in C# as well, check this link; this was my source.

Application error The memory could not be read 0x00000014

Hi everyone,
I would like to know if any of you have come across this issue.
I'm running an application built by me in a computer with LabVIEW Run-time 9 in which I display a PDF file using an ActiveX control:
The target computer runs Adboe Reader 9.0. Everything works perfect until the application is closed. From time to time (nearly most of the times), I've got the next windows error:
"Application Error: The instruction at "0x0ffd609c" referenced memory at "0x00000014". The memory could not be "read". Click on OK to terminate the program".
Trying to find out the reason, I found a couple of forums which claim that the reason is a bug in Adobe 9.0 (actually, I've tried running the application with Adobe Reader 8 and I cannot repeat the error). Any of you have had this error before and found a solution? Those links weren't about LabVIEW and I have no idea how to get around this issue.
Any help is appreciate it.
Thanks in advance.
Dani
Solved!
Go to Solution.

To who may be interested, I managed to find a workaround for this bug in Adobe Reader 9.0.
It seems that, somehow, LabVIEW, and other programming tools, straggle with this version of Adobe (I assume that this is due to this bug) when closing the reference to Adobe created by the ActiveX container. So the solution would be closing "by hand" this reference, and telling Windows to free all the relation between the application (LabVIEW for us) and Adobe. The idea is that when we've done with the VI which displays the PDF via ActiveX, we should close the reference to the ActiveX control, close the reference to the VI, and:
- process all the Windows messages currently in the message queue (.NET: System.Windows.Form.Application -> DoEvents
- run CoFreeUnusedLibraries in "ole32.dll"
I hope this information can help somebody, as I wasted too much time to figure this out (finding eventually the answer in a forum of Adobe!)
P.S. For those who program in C# as well, check this link; this was my source.

Upon exiting LV7: Application Error-Memory could not be read.

Upon terminating my application, I get the following error:
"LavVIEW: LabVIEW.exe - Application Error
The instruction at referenced memory at . The memory could not be 'read'."
So far the error seems non-critical. It does not appear to affect the performance of the program in any way. However, it is certainly unnerving for my end users (not to mention me)!
The error occurs in both the executable and the debugging mode. I have traced it to the VERY END of my application, which runs flawlessly until the very moment when I use the Exit instruction. I have also tried using Close FP with Abort VI, as well as Close FP with Exit. All threads in my application have successful
ly terminated, so aborting does not stop any action in mid-execution, as far as I am aware.
Searching for others in the forum who have had similar problems has turned up little useful help. Could this be a bug in the (god forbid!) runtime engine?!
Here's a link to a discussion of the closest thing I could find to my problem.
Thanks for any help you can give. Any whatsoever.
-Nick
"You keep using that word. I do not think it means what you think it means." - Inigo Montoya

> Hmmm... I'll look into it. Many or all of the DLLs that I call were
> written in Delphi, which has at least three string types that come
> into play: regular Pascal String, PChar (Delphi's re-creation of the C
> string type), and the ShortString type, which is sized to 256 bytes
> (if memory serves). From your response, it sounds as if I should
> search for those DLLs that use the ShortString type.
>
> Also, I encode many complex data forms and pass them into the DLLs as
> array pointers. These also sound like places to start looking.
>
> Thanks for the input. If I ever track down the problem, I'll update
> this discussion for posterity. In the meantime, if anyone else out
> there has any more thoughts, I'd sure appreciate them.
To h
elp track it down, if you can build a debugging version of the
Delphi DLLs, especially something that will validate memory references.
One of the great tools for tracking down memory overwrites is a well
implemented debugging memory library. Also, if you have some notion of
DLL calls that write to the string and return it to LV, that would be
the first place to look. And in the end, the solution is usually to
look at the assumption of the DLL and send in a larger preallocated
string. So in some cases it is easiest to look for the strings and
arrays going into DLL node calls and one at a time give them large input
sizes looking for the closing crash to go away. Then when the symptom
goes away, look at the code for that DLL.
Greg McKaskle

What can I do about "LabVIEW load error code 38: Failed to uncompress part of the VI."

While attempting to load an executable LabVIEW application for LabVIEW 2009 SP1 on a Windows-XP machine when the following pop-up message occurs. "LabVIEW: Memory or data structure corrupt. An error occurs in loading VI 'NI_Gmath.lblib: Backward Bracket Search.VI'. LabVIEW load error code 38: Failed to uncompress part of the VI. The VI is most likely corrupt." What seems odd is that the same LabVIEW application loads fine when logged on as a privileged user account, but fails to load on a private user account.
Attachments:
2012-07-18 LabVIEW Load error code 38.jpg ‏1314 KB

Here's a thought:
So when something is decompressed, a temp folder is often used.
I have no idea why LabVIEW would be decompressing anything, but I suspect it is trying to put the decompressed file into a temp folder where the user does not have write permissions.
In the .ini file for your executable, you can add a line that specified the location of the temp folder to use:
tmpdir=C:\Temp
On my Win7 machine, the location is:
C:\Users\MyUserName\AppData\Local\Temp
On WinXP, it is probably:
C:\Documents And Settings\YourUserName\local settings\temp
Try changing the tmpdir key in your ini file to something to C:\Temp and see if that helps.
- john

LabVIEW Lode Error code 3

I have installed the LabVIEW runtime engine on a machine that does not have LabVIEW installed. I then exported my program to a .exe using the project manager. When I went to run the .exe, I get an error message that says "Application failed to start because instrsup.dll was not found" and it suggests re-installing the application (though they don't specify what "the application is," the run-time or the .exe?) may solve the problem. When I click "OK" a second error message pops up that says "An error occurred loading VI 'dat4700outputvalue.vi' LabVIEW load error 3: could not load front panel. "When I click OK on the 2nd error message, the 1st message comes up (with one ofthe other Datron driver .vis), and it cycles between the two until I have said "OK" to each error message about 10 times. After clicking "ok" on the 2 error messages enough, the front panel finally shows up, along with a 3rd error message that says "missing sub.vi dat4700 initialize in VI TVC Cal warmup" along with all of my other drivers for my Datron 4700.
It looks like all of my drivers for my Datron 4700 don't make it into the program for some reason. I have tried re-compiling the program through the project manager and it still doesn't work.
Any ideas? The only other thing I can think to try is just re-installing the run time engine...

You will need to provide the link. The only Datron 4700 in the NI Instrument Driver Network is a LabWindows driver - not LabVIEW at all and your mention of a dll shows that it is not a native LabVIEW driver. Do you know for a fact that the driver does not require anything additional such as the CVI run-time or the IVI Compliance Package?

I have been asked by my IT department how a LabVIEW application is secure

In general how does a standard LabVIEW application respond to these requirements:
The runtime environment shall not be susceptible to buffer overflows, SQL injection, LDAP and XPath injection, code injection or any other injection flaws. Malicious file execution and insecure direct object references shall be prevented at all times.

I know certain ActiveX actions that are deemed "security risks" will now generate errors in the LabVIEW Run Time Engine unless the registry of the host computer has been specifically modified to allow such ActiveX calls.
I guess my point is, NI does take some steps to prevent some issues at the run-time level regardless of how your code is written, so if that is the level <they> are concerned about, I would reach out to my local NI Field engineer and/or NI Customer Support and ask for help in how to answer <them>.
As Sam_Sharp pointed out, there are several things that are difficult/impossible for the RunTimeEngine to protect against, in any language. If the author of the code does stupid things or deliberately has maliscious intent, there are many things they can do that is outside the bounds of an RTE. In LabVIEW, some of the 'holes' in other languages are hard (impossible??) to do. For example, you as a coder, do not have access to creating and manipulating pointers, so you can't create code that intentionally overwrites other [edit: memory-]sectors in the host machine memory. So that would also be a case of where the run-time-engine (and its memory manager) plugs (or significantly shores up) things and makes it "safer".
The main security threats I see coming from the LV RTE engine is that there is no way the RTE can protect against malicious file removals, file hashing, injecting bad commands and/or data into network(s) and databases etc., beyond the protection offered by the OS (file/folder permissions) and IT infrastructure (firewalls, database query protections etc.).
Not sure any of that helps you out or not.. A dialoge with NI seems required for you, perhaps bring together reps' from both parties (NI field engineer and your IT people) so that they can get a line of communication going.
QFang
CLD LabVIEW 7.1 to 2013

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

Application error nicitdl5.exe

When I shutdown my windows XP - windows application error message - nicitdl5.exe. Not sure why?
Lookout version 5.1 Build 8
Many Thanks!

I'm running Labview 8.6 on Windows-XP and I get...
Runtime Error!
Program C:\Windows\system32\nictdl5.exe
This application has requested the Runtime to terminate it in unusual way.
Please contact the application's support team for more information.
...when I shutdown windows.
I don't know why it happens but I can't prevent it if I manually stop the service 'National Instruments Citadel' before shutting down. This must be done every time you shut down. I don't know any other way to solve this.

MCshield.exe - Application Error

I get the following error in my applications:
===================================================
Mcshield.exe - Application Error
===================================================
The exception unknown software exception (0xe0070001) occured in the application at location 0x77f1d479.
Does anyone knows the meaning of this errors and the consequences ?
Greetings
Davy

That would be your virus protection failing (McAfee). So it's not likely a LabVIEW problem. It could be a bad installation of the virus shield. The consequence is no virus protection. Beware the worms today:
http://www.cnn.com/2003/TECH/internet/08/12/windows.worm/index.html
2006 Ultimate LabVIEW G-eek.

Error "Please wait while the application opens: BlackBerryLink.exe - Application Error"

After several installations, disinstalls and reinstallations I am completely unable to use BlackBerryLink on my Windows7 PC: The error message provided immediately after launch of BlackBerryLink is with the title
   "Please wait while the application opens: BlackBerryLink.exe - Application Error"
with detailed message:
   "The exception unknown software exception (0xe0434352) occurred in the application at location 0x75cf812f."
Please provide any advice! My brand new Blackberry Z10 like this is only useful at 50% (since the encrypted SD card is not recognizeable as a normal SD card by my PC), and I would prefer not being forced to byuy other smartphones...
thanks for any advice
Knut

Hi Kodee,
1)     Are using error handling in your code? Are you getting any errors?
2)     What version of LabVIEW are you using? If you are using 8.0 or newer, then you can build a debuggable executable:
Debugging Applications and Shared Libraries
http://zone.ni.com/reference/en-XX/help/371361A-01/lvhowto/debug_apps_dlls/
Regards,
Elizabeth S.
Applications Engineer
National Instruments

Nimax.exe - Application Error. Instruction at 0x6d8e3e61 referenced memory at 0x00000000. The memory could not be "read."

On startup I get a nimax.exe application error.
The instruction at "0x1ce30df7" referenced memory at "0x00000000". The memory could not be "read".
This happens every time I start the computer, run a vi with the initialize.vi or try to use the measurement and automation explorer.
I am running windows XP, Labview 7.1, and max 3.1.1

I had a similar problem in win2000 / max 3.1.1. I do not recall the exact memory location error.
It happened every time I started the computer, or once started, evrytime I load a vi that has some daqmx functionlity.
I reinstalled windows / Nidaq, and never had the error again.

Labview Application Error

Similar Messages

Maybe you are looking for