Labview Access Violation

Hello everyone,
I have developed a VB GUI which controls the Test Stand API and runs sequence files made up of LabView code modules. Thanks for the help so far everyone! I seem to have progressed from 'newbie' to 'rookie'.
However........ I am having another problem now! Whenever I run my sequence (either from the VB Panel or directly from Test Stand) the second run almost always comes up with a LabView access violation (0x00005) and kills LabView.
This only ever occurs on 'Single Pass'. On 'Test UUTs' the problem doesnt occur. I may just create my own Model by copying Test UUTs and making it do what I need it to. But can anyone think of a reason for this?
Thanks
Marlon

Hi,
As a suggestion:
Try running one of the demo sequences such Computer Motherboard Test Sequence.seq either in your GUI or the seq editor or both. That will eliminate any corruption problems. Make sure you are using default Process Models etc.
If every thing works with the demo seq, then its something in your sequence. Maybe a driver making an illegal call.
Regards
Ray Farmer
Regards
Ray Farmer

Similar Messages

LabVIEW Access Violation Crashes

We've been seeing numerous LabVIEW crashes when calling VIs through the LabVIEW adapter in TestStand. I've searched the knowledge base and discussion forums without success and figured I would post here before opening a help request.
The actual error we see is:
Exception: Access violation (0xC0000005) at EIP=0x012B60E6 Version: 11.0.1f1
We see these crashes several times a day, but while calling no specific VI. They happen mostly on 2 PCs that are running Windows 7 - 64 bit, but I think we've seen them in the past on PCs running the 32 bit version of Windows 7. Here is the data related to those 2 problematic PCs.
OS: Windows 7 Professional SP1 64 bit
LabVIEW: 2011 SP1 (11.0.1f1) 32 bit
TestStand: 2010 SP1 (4.5.1.134) 32 bit
PC: Dell Optiplex 790 with Intel Core i5
Other significant information.
We see these crashes when we're running the batch model in TestStand with multiple threads open. Some VIs are reentrant, and some are not.
The 2 PCs that run the batch model (with multiple threads) have the 64 bit version of Win 7 Pro, and crash most often.
The 3 PCs that run the sequential model or the batch model with a single thread have the 32 bit version of Win 7 Pro and rarely if ever have crashed.
Not sure if it's related to the OS version or the multi-thread usage and switching the PCs/OS versions to isolate that isn't easy.
Has anyone else seen similar issues? Does Windows 7 Pro 64 bit work reliably with LabVIEW 2011 32 bit?
Any information would be appreciated.
John Morrissey

Hi Amezam, thanks for your reply.
We appear to be having different access violations each time (or they are one of a large group of them, we cannot tell).
The crashes appear to be at random, we cannot connect the crashes to any specific sequences of events and we cannot reprocude the crash consistently on the same piece of code! One pattern I have noticed, however, is that the violations appear to coincide with a peak in program activity - very frequent indicator updates for instance*.
I am unable to disable antivirus protection at will, but I will raise it with our IT Support to see if we can try that.
I believe that we are intearacting with external code - 3rd party device drivers which include packed libraries. I have no control over these and, furthermore, if I were to remove them the code would not be able to function at all. However, if you think it is a good idea I can attempt to create a separate piece of code which calls the same driver function very rapidly to see if that is the problem.
As for error handling - those nodes which use them only return error codes from the base 3rd party libraries, which according to the documentation only return custom error codes (these are not related to the error/crash that we are seeing). If you think it's still possible that they will return an Access Violaton error and crash, I will link them up.**
* - sidenote: I implemented a method of reducing the number of updates to a graph indicator (from several times a second to several times a minute) - this has reduced the problem significantly.
** sidenote 2: Some of the nodes which return custom errors are linked properly, and they are not returning errors; these ones are the most likely to return errors since they are called extremely frequently. I am not seeing anything except the documented custom error codes from them.

LabVIEW Access Violation Crashes from TestStand

We've been seeing numerous LabVIEW crashes when calling VIs through the LabVIEW adapter in TestStand. I've searched the knowledge base and discussion forums without success and figured I would post here before opening a help request.
The actual error we see is:
Exception: Access violation (0xC0000005) at EIP=0x012B60E6 Version: 11.0.1f1
We see these crashes several times a day, but while calling no specific VI. They happen mostly on 2 PCs that are running Windows 7 - 64 bit, but we've seen them in the past on PCs running the 32 bit version of Windows 7. Here is the data related to those 2 problematic PCs.
OS: Windows 7 Professional SP1 64 bit
LabVIEW: 2011 SP1 (11.0.1f1) 32 bit
TestStand: 2010 SP1 (4.5.1.134) 32 bit
PC: Dell Optiplex 790 with Intel Core i5
Other significant information.
We see these crashes when we're running the batch model in TestStand with multiple threads open. Some VIs are reentrant, and some are not.
The 2 PCs that run the batch model (with multiple threads) have the 64 bit version of Win 7 Pro, and crash most often.
The 3 PCs that run the sequential model or the batch model with a single thread have the 32 bit version of Win 7 Pro and rarely if ever have crashed.
Not sure if it's related to the OS version or the multi-thread usage and switching the PCs/OS versions to isolate that isn't easy.
Has anyone else seen similar issues? Does Windows 7 Pro 64 bit work reliably with TestStand and LabVIEW 2011 32 bit versions? I posted this question in the LabVIEW discussion forum, but I don't know where the issue resides, I'm posting in the TestStand forum also.
Any information would be appreciated.
John Morrissey

I just had the same error in a LVOOP Project. First I got a crash (something with out of memory). The I got subsequent Access Violations. Could trace it down to one VI that:
a) had been working just fine before
b) wasn't changed after test mentioned in a) but got (even just running on its own) subsequent access violations every time I ran it
c) VI used a class konstant, property node (to set 2 class attributes); Inputs were a string and an integer and an error cluster; outputs: one instance of the class (initialized with string an integer) and the error cluster
d) Problem could be solved by deleting the class constant used in the VI and put the same in again (an just rewired the thing); I assume this caused a recompile that solved the prob
Maybe this helps narrowing the general problem down.
P.S: I dont have a still non working version of that VI, since I was happy to have solved this and just saved the VI before thinking about making a copy.

How to resolve and debug access violation Error.

Hello
I'm stucked with an access violation error which forces my exe build to shut down. I tried also from development environment but its the same there. The error happens after 5-60minutes.
I played around with disabling a part of the program where it was possible and I think I'm now able to accuse the vi "gastimer.vi". But since this vi leads through the measurement procedure, there are some commands outgoing which I was not able to map one to one.
My question is: what can cause such access violation errors? I have no dll calls, no third party library, actually the hardware communication is done serial by COM ports. The architecture principle is something adapted from producer consumer loop, except that i have often more than one consumer, so I called them like controller loop - multiple task. The communication within this loops (tasks) are done by queue cluster with an enumerator and variant.
The indicted vi "gastimer.vi" was transfered from an older and more simply architecture. This vi works with sequence structure and a lot of local variables.
Since I'm testing sensor on their response to gas concentration I have 10 comports to which I'm listening in parallel.
What styles or archtiecture are prone to access violations? Where can they happened? where should I look more carefully in the code?
How can I use the desktop execution trace toolkit to get more information about the cause of the access violation?
Attached are two different lvlog but I guess with the same error source. In the second lvlog are two vi's named. What have they to do with the access violation error? What kind of information can i get from these lvlog files?
Last attachement shows a runtime fatal error which happens quite a bit frequently in the recent time when working with this project. Might there be a connection, propably a crashed vi, typedef or whatever?
Thanks for any help
U. Siegenthaler
Solved!
Go to Solution.
Attachments:
first.zip ‏203 KB
second.zip ‏40 KB
Fatalerror.PNG ‏21 KB

Have you checked your code to try to isolate any areas of possible memory leaks? I was able to find some discussion forums with similar problems. Check out the links below to see if any of these resources can be of assistance to you.
"Exception: Access violation (0xC0000005) at EIP=0xFDD76383"
http://forums.ni.com/t5/LabVIEW/Exception-Access-violation-0xC0000005-at-EIP-0xFDD76383/m-p/2257502
"Exception: access violation (0xc0000005) at EIP=0x00BD0984 "
http://forums.ni.com/t5/LabVIEW/Exception-access-violation-0xc0000005-at-EIP-0x00BD0984/m-p/2303864
"Access violation (0xC0000005)"
http://forums.ni.com/t5/LabVIEW/Access-violation-0xC0000005/m-p/2269694
Let me know what you find and if you have any other questions.
Best regards
Matijas

Access violation (0xC0000005) at EIP=0x012B60E6 within a dynamically called VI

Hi
I have been seeing Access violation (0xC0000005) at EIP=0x012B60E6 within a dynamically called VI.
The VI is called by reference and is strictly typed.
The VI controls a function generator, a robot and a microcontroller device.
All of the above are synchronised using functional globals.
If I let the code run the FG will operate so I know the top level dynamic VI has defiantly been called and successfully entered, however within that VI as other VI’s are called (there are many) LV crashes with access violation.
The VI's within the top level VI are using HiD communicatiuoins over USB with the peripheral instrumants.
The LV crashes are totally random and sometimes the code will operate until the end and close down successfully.
I can only seem to guarantee smooth operation if I set a breakpoint within the top level VI, then the entire system runs perfectly.
In fact it seems that even if I remove the breakpoint (after the first break) and close the VI the system will continue to run until close.
Has anyone any ideas? I have run out!

Hi MAC1,
I have been looking at your issue and wanted to ask if you are calling the VI's into Teststand, using the LabVIEW adapter?
If this is the case, it may be worth looking at another forum post regarding the issue.
LabVIEW Access Violations- Teststand
I am currently looking into what could have caused this access violation.
If you could provide any further information in regards to the top level VI or if you could post it on here, that would be really useful.
Regards,
Dom C

Why does labview generate Dr. Watson error "C0000005 access violation"

I am running Labview 5.1.1 in Windows 2000 Professional on a machine with the following configuration
*----> System Information <----*
Computer Name: ANDANTE
User Name: Administrator
Number of Processors: 2
Processor Type: x86 Family 6 Model 8 Stepping 3
Windows 2000 Version: 5.0
Current Build: 2195
Service Pack: 4
Current Type: Multiprocessor Free
I have all of a sudden begun to experience labview crashes. The crash occurs systematically after tens of minutes; not just a few minutes, but not more than an hour or so. I am running a vi but not actively interacting with the machine (no other applications running, not even moving the mouse around). The problem happens even when running a vi that I have run successfully for extended periods of time (overnight) only 3 months ago. I have tried it with two different vis, one that I have recently made a lot of modifications to and another that has not been touched for months (since before the crashes began), and it happens with both vis. They do much different things (communicate with different GPIB or PCI boards, write to different kinds of files in different locations, etc.), so the problem seems to be vi-independent.
When the crash occurs, I see a dialog appear with the error
labview.exe has generated errors and will be closed by windows. You will need to restart the program. An error log has been created.
The Dr. Watson error log is generated and the error is
Application exception occurred:
App: (pid=1160)
When: 4/25/2004 @ 01:57:56.640
Exception number: c0000005 (access violation)
I always get the same Dr. Watson error information -- i.e., it is very reproducible. I don't really know how to interpret the rest of the Dr. Watson log, but I include the report on the first thread, which is the one with the "FAULT" in it, at the end of this email.
Looking around on the web, it may be that a temporary virus infection could have created the problem. In the period since the machines was last successfully used, I have seen two files be infected by the W32.Welchia.B.Worm virus, the files were svchost.exe and WksPatch[1].exe. These files have been quarantined and no other infected files have been found since this error began to appear.
Any ideas? I've seen on the web that reinstalling Windows 2000 and/or upgrading to Labview 7.0 might solve the problem, but it would be nice to get some confirmation before taking the time/spending the money.
Here is the state dump for the thread with the FAULT in it, as provided by Dr. Watson:
State Dump for Thread Id 0x574
eax=00000062 ebx=00000000 ecx=00000000 edx=00000004 esi=00000000 edi=05692214
eip=00748236 esp=0012fb28 ebp=0012fb28 iopl=0 nv up ei pl zr na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00000246
function: StrLen
00748230 55 push ebp
00748231 8bec mov ebp,esp
00748233 8b4d08 mov ecx,[ebp+0x8] ss:00ba9a0e=????????
FAULT ->00748236 8a11 mov dl,[ecx] ds:00000000=??
00748238 8d4101 lea eax,[ecx+0x1] ds:00a79ee6=????????
0074823b 84d2 test dl,dl
0074823d 7407 jz GetCDReg+0x6f6 (00750c46)
0074823f 8a10 mov dl,[eax] ds:00000062=??
00748241 40 inc eax
00748242 84d2 test dl,dl
00748244 75f9 jnz CfgRemove+0x44f (0074ae3f)
00748246 2bc1 sub eax,ecx
00748248 48 dec eax
00748249 5d pop ebp
0074824a c3 ret
*----> Stack Back Trace <----*
FramePtr ReturnAd Param#1 Param#2 Param#3 Param#4 Function Name
0012FB28 00737A74 00000000 00000000 05692214 00000400 !StrLen
0012FC40 00736A45 050753E4 05692214 0012FC6C 00736724 !SetKeyboardHandlerProc
0012FC50 00736724 05692214 0012FCB4 05692214 BDBC0000 !SetKeyboardHandlerProc
0012FC6C 00736627 05692214 0569232C 00000400 00000000 !SetKeyboardHandlerProc
0012FC98 0074B470 0012FCB4 BDBD0001 00000000 0569E8E0 !SetKeyboardHandlerProc
0012FCD0 0074ACD0 00000000 0074AC10 0569FFA4 010A2418 !CfgRemove
0012FCE8 007808D5 00000000 00000000 00000001 00000000 !CfgRemove
0012FD08 007ACEB6 00000000 00000000 77E18F95 00000000 !ChkOccurrences
0012FD9C 006033DE 00000001 00000000 77E2ADC1 007A5C80 !WMainLoop
0012FF24 007B2186 00400000 00000000 00000001 00000001 !WMain
0012FFC0 7C581AF6 005C0057 0061006C 7FFDF000 C0000005 !inp
0012FFF0 00000000 007B2030 00000000 000000C8 00000100 kernel32!OpenEventA
*----> Raw Stack Dump <----*
0012fb28 40 fc 12 00 74 7a 73 00 - 00 00 00 00 00 00 00 00 @...tzs.........
0012fb38 14 22 69 05 00 04 00 00 - 16 4d 65 74 68 6f 64 20 ."i......Method
0012fb48 4e 6f 74 20 49 6d 70 6c - 65 6d 65 6e 74 65 64 00 Not Implemented.
0012fb58 55 1f f8 77 18 25 f8 77 - 2f a8 fd 74 c4 01 00 00 U..w.%.w/..t....
0012fb68 05 a5 fd 74 d0 26 ce 01 - 00 00 06 01 10 04 00 00 ...t.&..........
0012fb78 00 00 00 00 00 00 00 00 - 2e fb 69 05 42 e9 69 05 ..........i.B.i.
0012fb88 c1 2f 7b 00 00 00 00 00 - 12 04 00 00 11 04 00 00 ./{.............
0012fb98 30 fb 69 05 12 04 12 00 - bb 35 7b 00 00 00 06 01 0.i......5{.....
0012fba8 11 04 00 00 00 00 00 00 - 00 00 00 00 2e fb 69 05 ..............i.
0012fbb8 35 34 7b 00 4c 34 7b 00 - 48 00 06 01 f8 fb 12 00 54{.L4{.H.......
0012fbc8 10 04 00 00 ec 53 07 05 - 11 04 00 00 08 fc 00 00 .....S..........
0012fbd8 ee c8 77 00 30 fb 69 05 - 11 04 00 00 00 00 00 00 ..w.0.i.........
0012fbe8 00 04 00 00 01 00 00 00 - ec 53 07 05 00 04 00 00 .........S......
0012fbf8 00 38 83 00 1c fc 12 00 - 23 ca 77 00 00 38 83 00 .8......#.w..8..
0012fc08 40 ff 69 05 01 00 00 00 - 00 00 00 00 2d 00 00 00 @.i.........-...
0012fc18 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
0012fc28 00 00 00 00 00 00 00 00 - 00 00 00 00 01 00 00 00 ................
0012fc38 50 fc 12 00 1a 6a 73 00 - 50 fc 12 00 45 6a 73 00 P....js.P...Ejs.
0012fc48 e4 53 07 05 14 22 69 05 - 6c fc 12 00 24 67 73 00 .S..."i.l...$gs.
0012fc58 14 22 69 05 b4 fc 12 00 - 14 22 69 05 00 00 bc bd ."i......"i.....

For questions like these, you are better off contacting NI directly. Goto www.ni.com/ask for directions. It has been my experience that Dr. Watson error logs are only useful as supplementary information. It is best for support and for the forum if you can provide a clear description on how to cause the error consistently.

LabVIEW Class crash - ntdll.dll access violation

Hi,
When I close my LV11SP1f2 I always get a warning.
It didn't bother me until a vi I wrote that uses a class with nothing out of the ordinary started crashing my LV.
The crash says that: "DAbort 0x37C03D in MemoryManager.cpp"
I sent the log files to the local support and they saw that the common issue between my logs is an access violation in ntdll.dll.
Any operation that uses the property nodes of that crazy class fails, sometimes with a crash and sometimes with a error that sends me to a bundle by name in the autocreated property node.
I rewrote the project with the class and there is no error.
Sending the crashing project to another computer gave no error.
Before I go on and investigate windbg to search for a conflicting app and finally formatting my entire computer could some1 help? Please...
I attached several logs for example.
Thanks in advance,
GoofyWires.
Attachments:
92c82e7b-fa2a-43af-b2be-a6650c031681.zip ‏2485 KB
daa462b5-9395-4e3f-8894-05a3bdb3d159.zip ‏65 KB
ea2c40ef-056d-41ed-a4c5-9cf4bc6666fc.zip ‏494 KB

I did a clean format and reinstalled LabVIEW 11.0.1f2 without adding many of the add-ons from VIPM and without installing the rest of my shortwave, yet, the crash is still here!
I was able to reproduce it on my pc:
1. I have a class that contains two children of another class which each contain another class with a class inside it.
2. I accessed the classed through property nodes.
3. I then went on and deleted a private data from the first class control, deleted its property nodes and added a new private data to that class control and added the property nodes for it.
4. I updated the vi that used the classes to stop using the deprecated property node and start working with the new one.
5. I did a "save all" and run the vi. All OK!
6. I closed LabVIEW and reopened the project and run the vi which is not broken! LabVIEW crashes!!!
I guess the complexity of the class is not the issue and it can be reproduced in a much simpler way.
Yet, since I bet the scenario caused you to raise an eye brow I'll give an example as an analogy:
File Handler class contains ASCII Read class and ASCII Write class which inherit from class ASCII.
Class ASCII parent contains class Headers while class Header contains class Data.
Thus, class ASCII Handler will use class ASCII Read/Write to give a high level simple interface while during the read/write the inner ASCII Read, for example, will add to the Header class in it the read data which will in turn be added to the array in the private data of class Data.
I'll try and reproduce it on a different pc and send the local NI support the code and way to reproduce.
I see two possibilities:
1. Something is wrong with my new Dell PC.
2. LabVIEW doesn't handle and propagate correctly changes in a class to all the vis that use it. Maybe changing the array size in a class overrides some memory since the class can't change its size.
Please let me know if this rings a bell.
Update: I coundn't reproduce the crash on my pc with a simpler case. There is something missing...
I'll try to replroduce with the complex class on a different pc and if it crashes I'll simply send my original code.

Labview application crashes with a Dr Watson Access violation c0000005 in win2K service pack 2 and 3

The application was developed on a Dell Optiplex PIV 2GHz, 512 MB Ram using LabVIEW 6.1 Profesional Control Development Suite. The exe runs for between 10 minutes and 21 days before exiting with a Dr Watson Access Violation error 0xc0000005. The basic stack dump info is as follows:
Application exception occurred:
App: (pid=312)
When: 2/4/2003 @ 20:54:51.843
Exception number: c0000005 (access violation)
*----> System Information <----*
Computer Name: NO1
User Name: No1
Number of Processors: 1
Processor Type: x86 Family 15 Model 2 Stepping 4
Windows 2000 Version: 5.0
Current Build: 2195
Service Pack: 2
Current Type: Uniprocessor Free
Registered Organization: xxxxxxxxxxxx
Registered Owner: xxxxxxxxxx
*----> Task List <----* edited for brevity
312 xxxxxxx.exe
1056 drwtsn32.exe
0 _Total.exe
State Dump for Thread Id 0x38c
eax=78e34ff8 ebx=79288ab8 ecx=00000001 edx=78e338cc esi=78e34ffd edi=78e338d1
eip=3027bf0d esp=0012fc70 ebp=0012fc7c iopl=0 nv up ei pl nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00000202
function: MoveBlock
3027bef7 fc cld
3027bef8 eb15 jmp CheckFPStat+0xe52 (3027ce0f)
3027befa 0fbae100 bt ecx,0x0
3027befe 7301 jnb CheckFPStat+0xa344 (30286301)
3027bf00 a4 movsb ds:78e34ffd=32 es:78e338d1=00
3027bf01 d1f9 sar ecx,1
3027bf03 0fbae100 bt ecx,0x0
3027bf07 7302 jnb CheckFPStat+0x654e (3028250b)
3027bf09 66a5 movsw ds:78e34ffd=3532 es:78e338d1=0000
3027bf0b d1f9 sar ecx,1
FAULT ->3027bf0d f3a5 rep movsd ds:78e34ffd=???????? es:78e338d1=00000000
3027bf0f 5e pop esi
3027bf10 5f pop edi
3027bf11 59 pop ecx
3027bf12 8be5 mov esp,ebp
3027bf14 5d pop ebp
3027bf15 c3 ret
The error is always "move block" and leads me to believe that it is a windows memory manager issue but I cannot resolve it. The application connects to an ethernet GPIB interface and to 10 Opto22 Ethernet brains via activeX. The processor runs about 25%, there are no apparent memory leaks, and there is at least 300Mb of free ram when the crashes occur. Any suggestions?
Thanks,
Ian

I am having the same issue with LabVIEW 7.1
From Dr. Watson:
Microsoft (R) Windows 2000 (TM) Version 5.00 DrWtsn32
Copyright (C) 1985-1999 Microsoft Corp. All rights reserved.
Application exception occurred:
App: (pid=2208)
When: 10/21/2005 @ 13:09:12.530
Exception number: c0000005 (access violation)
*----> System Information <----*
Computer Name: WEESUSCILPCWRM0
User Name: RDL
Number of Processors: 2
Processor Type: x86 Family 15 Model 4 Stepping 1
Windows 2000 Version: 5.0
Current Build: 2195
Service Pack: 4
Current Type: Multiprocessor Free
Registered Organization:
Registered Owner: Administrator
*----> Task List <----*
0 Idle.exe
8 System.exe
168 SMSS.exe
192 CSRSS.exe
188 WINLOGON.exe
240 SERVICES.exe
252 LSASS.exe
396 scardsvr.exe
472 svchost.exe
500 spoolsv.exe
568 dklog.exe
592 svchost.exe
616 FrameworkServic.exe
688 mcshield.exe
708 vstskmgr.exe
728 naPrdMgr.exe
844 regsvc.exe
860 mstask.exe
900 Smc.exe
1020 WinMgmt.exe
1048 Wuser32.exe
1076 CcmExec.exe
1188 dkcktkn.exe
1876 svchost.exe
916 explorer.exe
2172 shstat.exe
1988 tbmon.exe
1200 UpdaterUI.exe
2012 dkAutoReg.exe
2072 ERClient7.exe
1916 LabVIEW.exe
2288 notepad.exe
2284 notepad.exe
2208 WINWORD.exe
2424 agentsvr.exe
1900 DRWTSN32.exe

Labview crashes with access violation(0xc00000050at EIP=0x7c8219a6

when i poen my project in labview ,it crashes with "access violation(0xc00000050at EIP=0x7c8219a6.why is this happening?how can i open my project?

Probably nothing to do with it but I had some dodgy memory, and windows would complain that there was an error to do with that exact memory location: c0000005

Crash: "Access violation (0xC0000005)"

Hello,
One of our programs has crashed (crash of LabVIEW Runtime).
The reason was an "Access violation (0xC0000005)" in the LabVIEW Runtime.
Because it was an Error of the LabVIEW Runtime, I can not log the Error. This Error occurs only very seldom > than every 3 weeks.
Attached is the error report and a Screenshot of the Error Window.
So I have no Idea how to locate the error.
1. What can cause this Kind Error?
2. How can I locate the error cause?
3. Can National Instrument isolate the error?
Thanks
Sletrab
Attachments:
Error Window.jpg ‏20 KB
1ba236e7-4073-4e5e-9fe2-517a4eb8d8da.zip ‏40 KB

These types of crashes are very conserning, and difficult to isolate (as you already have discovered). Here's what I've done in the past.
Memory monitoring. Built into Windows 7 and newer is the Performance Monitor. Not sure where it is I always click Start then type Performance Monitor. It lets you log data over time and I usually set it up to log my application (or LabVIEW.exe) and look at different memory. There are all kinds of memory from private, to public, and several variations in between. This it self doesn't fix anything but may help in predicting when it happens. If memory increases at some rate and it always dies around the same value it might help.
If you can predict, and reproduce the issue, try changing the code to see if the issue goes away, or happens faster. For me I made my logging routine run twice as fast. So for all data I log I log it twice. If the issue happens sooner it is likly something in the logging routine.
After that I did a binary approach where I would disable parts of the logging code until the issue when away. Turns out it was a bug in the TDMS logging routine that I could isolate and post to the forums. NI agreed and fixed it in an update, and also had a work around until the update went live.
Another thing I've tried is to upgrade to the latest everything and see if it behaves differently. I would make an image of the harddrive as a backup, then upgrade to the latest LabVIEW and drivers for everything. Then try again. In a few cases things were fixed by upgrading, and the cost of upgrade was less than the weeks it would take for me to track down issues that may or may not be my fault.
EDIT: Oh and giving the crash report to NI is a good place to start. Not sure what they can understand from it.
Unofficial Forum Rules and Guidelines - Hooovahh - LabVIEW Overlord
If 10 out of 10 experts in any field say something is bad, you should probably take their opinion seriously.

TestExec Access violation After Exit !!

Appreciate Any help I can get with this error !! Its driving me nuts !!
Firstly, on my development PC all the compiled applications function as expected, the problem lies with the target PC. I have set all applicable executable files (labview compiled projects) to run with admin rights, even though I am using a admin windows user account just to be sure. Both PC's are running windows 7 professional with the latest service packs and updates installed. No virus software is running on the target machine either.
Overview Description of my implementation:
Parent Application (labview compiled) - launches using the command prompt (system exec) a shortcut link to my TEST STAND operator interface which through the parent application allows the operator to select specific sequence test files. I setup system exec to run minimized and wait until completion.
Operator Interface - Runs the sequence file, all error handing comes back clean and once I quite the operator interface. Returns me back to the parent application from which it was called.
As the operator interface is closed down, (modified SIMPLE USER INTERFACE, which comes standard with TESTSTAND) I get a access violation error as the parent application regains focus. This error only occurs on my test PC, not on my development PC which would indicate there is probably nothing wrong with my logic but a mystery setting on the target PC.
Has anyone encountered a similar problem before, if so how did you fix it. ANy help is appreciated.
Best regards,
Sven

Sven.S wrote:
I have done further investiation.
1 - if I call the operator interface shortcut file directly through windows, the same access violation occurs !!
So you already tested the UI without the "parent application"?
Does it crash when it shuts down or if it loses the focus?
Does the unmodified Simple OI run without crash on this machine?
Does the crash occur if you call an example sequence (the crash might be connected to your custom sequence....)?
Do you use a default process model?
You should have posted this question in the TestStand forums.....
Norbert
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.

Access violation (0xC0000005)

Hi
I am getting continuing problem with the crashing and Access violation (0xC0000005) at EIP=0x00962D22.
When the crash happens the vi is gettting corrupt and impossible to open next time, so I need to work of the back up.
I tried to recompile everything, change the type defs, update to LabVIEW 12, open on another PC, same thing. I can work for 10min save the work several times do different things, and at one point LV crashes with that error.
Any ideas what to do? It is really a show stopper for me.
The report dump below.
thanks
#Date: Thu, Jan 03, 2013 3:42:12 PM
#OSName: Windows 7 Enterprise
#OSVers: 6.1
#OSBuild: 7600
#AppName: LabVIEW
#Version: 12.0f3 32-bit
#AppKind: FDS
#AppModDate: 10/05/2012 00:12 GMT
#LabVIEW Base Address: 0x00400000
<DEBUG_OUTPUT>
1/3/2013 3:44:28.199 PM
Crash 0x0: Crash caught by NIER
File Unknown(0) : Crash 0x0: Crash caught by NIER
minidump id: 7eb8157a-59f0-40af-acb9-a7b7df11beb2
ExceptionCode: 0xC0000005
</DEBUG_OUTPUT>
0x01AF1179 - LabVIEW <unknown> + 0
0x01AF1688 - LabVIEW <unknown> + 0
0x7C37FDB4 - MSVCR71 <unknown> + 0
0x771973E7 - ntdll <unknown> + 0
0x77159F15 - ntdll <unknown> + 0
0x00000000 - <unknown> <unknown> + 0
*** Dumping Bread Crumb Stack ***
*** LabVIEW Base Address: 0x00400000 ***

pawel,
I found your post here very interesting as I was having a VERY similar problem. The only notable difference I could find with my situation is I only seemed to encounter this problem on 64-bit systems, and only when my application was a deployed exe. However, I too was using a number of 3rd party .ocx and .dll utilities. But this stubborn Access Violation error was so sporadic (it might have triggered 5 seconds into execution, or 5 hours) it was near impossible to track exactly WHY it was happening.
Have you tried using the LabVIEW Desktop Trace Execution Toolkit yet? I used it to tap into my deployed executable on the target machine while monitoring all VI calls, memory adjustements, etc from my development machine. Although it wasn't a definitive sure-fire way to a solution, it did help me pin-point a pattern.
For about 80% of my crashes, I noticed the last applicable VI to execute (after filtering out a bunch of typical utility VI calls) was "Wait On ActiveX Event.vi". After a bit of digging, this VI was retired quite some time ago and has been upconverted from version to version since. It was written into a library that has been rock solid for years. Although it seemed to execute fine on my devlopment machine (as source code - not a built exe, 32 bit, 64 bit..whatever) and also functioned on all target 32-bit environments wrapped in an exe, it was actually the culprit to my Access Violation errors.
I know how frustrating it is to narrow something like this down. If you're still having issues and you haven't tried that Toolkit, I would suggest giving it a shot.
Good luck.
-Chris
Sr Software and Automation Engineer
Certified LabVIEW Architect
Kod Integrations, LLC
http://www.kodintegrations.com

Access violation (0xC0000005) at EIP=0x0534BABC when launching Exe

Hi All,
I am facing "Access violation (0xC0000005) at EIP=0x0534BABC" issue when I tried to launch my exe. Earlier versions of the exe were running fine until I added Email notification features using .net SMTP APIs and built it again.
System,
Development and Deployment systems are different. I am able to run source code on both systems and Exe on Developement system. But exe is not working in Deployment system.
Exception,
I have attached the sanpshot of crash report pop-up and Log Report of the exception.
Please help!
Anandelamaran Duraisamy,
Senior Project Engineer,
Soliton Technologies (P) Ltd,
www.solitontech.com
Attachments:
Crash Report.png ‏11 KB
Crash Report.zip ‏19 KB

Additional details,
When I tried "Run as administrator", I could see the exe icon on the task bar for few seconds then it disappears. It basically fails to launch, also I don't get any error message.
The Exe is created in development PC which runs 64 bit Window 7 and 32 bit LabVIEW. The deployment system has 32 bit Windows 7 and 32 bit LabVIEW. I hope it doesn't matter as far as my LabVIEW installations are 32 bit in both systems.
Anandelamaran Duraisamy,
Senior Project Engineer,
Soliton Technologies (P) Ltd,
www.solitontech.com

Access violation (0xC0000005) cause crash

Access violation (0xC0000005) cause crash. The crash report is as blow. It may be caused by the function IMAQ FillHole. How this function crash?
Who knows why? Thank you!
#Date: 2014年8月12日 14:21:51
#OSName: Windows 7 Ultimate
#OSVers: 6.1
#OSBuild: 7600
#AppName:
#Version: 12.0 32-bit
#AppKind: AppLib
#AppModDate: 08/12/2014 06:17 GMT
#LabVIEW Base Address: 0x30000000
<LVExec>
{"a":[
"vi": "D\\VISION_SYSTEM\\build\\MyProgram.exe\\IMAQ FillHole",
"ctx": "主应用程序实例",
"type": "subVI"
"vi": "D\\VISION_SYSTEM\\build\\MyProgram.exe\\ccd2表面2二值化.vi",
"ctx": "主应用程序实例",
"type": "subVI"
</LVExec>
<DEBUG_OUTPUT>
2014/8/12 16:48:15.894
Crash 0x0: Crash caught by NIER
File Unknown(0) : Crash 0x0: Crash caught by NIER
minidump id: 6e35643f-8ff2-49e6-bbde-98bac2ffa48a
ExceptionCode: 0xC0000005$N
</DEBUG_OUTPUT>
0x307277B4 - lvrt <unknown> + 0
0x30727B38 - lvrt <unknown> + 0
0x7C37FDB4 - MSVCR71 <unknown> + 0
0x77CA5A74 - ntdll <unknown> + 0
0x77C8B3C8 - ntdll <unknown> + 0
0x00000000 - <unknown> <unknown> + 0
Solved!
Go to Solution.
Attachments:
ccd2表面2二值化.vi ‏21 KB

Hi,
please stick with your original thread! Don't create double posts!
Best regards,
GerdW
CLAD, using 2009SP1 + LV2011SP1 + LV2014SP1 on WinXP+Win7+cRIO
Kudos are welcome

Profile error: Memory access violation (data fetch)

Hello,
I have VI with a lot of mathematic Nodes. When I try to profile it, I allways get this error: "Memory access violation (data fetch)".
Keil uVision shows this error:
"Memory write not possible (Real-Time Agent)
Memory read not possible (Real-Time Agent)"
Without profiling the VI works on the MCB2400. And profiling also works if I try very simple examples.
bye & thanks
amin

Hi Amin, Alex,
I noticed this issue had been open for some time, so I decided to post directly to save time.
Thanks,
Jaidev Amrite
LabVIEW Embedded PSE
Diagnosis: So apparently, this behavior has nothing to do with the profiler. The culprit is the Advanced Analysis SubVI call (Mean.vi) in BB.vi.
Mean.vi has a call library function node inside it and this CLN is configured to run in its own thread (labVIEW spawns a new thread for each call). Probably due to bad thread management on the ARM (in this case), this call causes a memory violation.
Solution:Turn off the "Run in any thread" setting on the CLN as shown in the attached screenshot - change it to "Run in UI Thread". For good measure also turn off reentrancy on Mean.vi (second screenshot)
National Instruments
LabVIEW Embedded Product Support Engineer

Labview Access Violation

Similar Messages

Maybe you are looking for