Access violation (0xC0000005)

[pawel]

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 ***

[The_Hunt]

Hello Pawel, 

The access violation error (0xC0000005) is a generic Windows exception error code, which can apply to a wide variety of situations and unfortunately makes it very difficult to debug. This error can sometimes be caused by an Antivirus software on your computer. I would first attempt to disable this software or even temporarily uninstalling the software and see if this error persists. 

This error and crash can also be caused by subVIs making calls to 3rd party DLLs. Does your VI have any subVIs included in the program? Do they make any calls to an external DLL/Library of some form? If so, I would suggest temporarily deleting these subVIs and see if the error and crash continue to occur. Doing this and removing your Antivirus software will help narrow down the source of this error. 

If you are in fact making calls to a 3rd party, then I would recommend that you contact this third party's support and ask if they know of any existing issues with the driver and version of LabVIEW that you are using. Also ask them to look into the DLL to confirm that LabVIEW is providing the parameters it needs to functions correctly. 

[pawel]

Thanks

Yes, this vi is full of 3rd party calls, ActiveX, Matlab, 3rd party graphics, etc. I also have Anti viral SW running but cannot remove due to CO policies.

I will start with Matlab.

Would you know how to make Matlab stop loading when vi calls it?

I am searching the web and so far I found "matlab -regserver" to activate the call, but how to deactivate it. Should be something simmilar.

thanks

[The_Hunt]

Pawel, 

You can use LabVIEW's stepping debugging tools to help narrow down which 3rd party call is throwing this exception error. You can also use the Diagram Disable Structure around individual functions that are making these calls to temporarily disable them. 

[pawel]

Hi

Is the stepping debugging available in Dev Env? How do I use it? Is it the button in the crash window saying "debug"? It needs VC++ installed which I do not have.

The crashing came back today and is happening every 10min after several CTRL+S. It is driving me crazy. I need to backup the entire project after each succesful saving of the vi. Otheriwse I will probably loose it.

I have made all Matlab calls encapsulated in conditional disable structure so I will see how that goes. Not sure what else I can do here. Any ideas are very welcome.

thanks

[lemieuxcw]

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

[pobrepablo1]

Hi Chris,

I'm having a VERY similar problem. I am waiting on ActiveX events for a camera. As you say, it happens 5 seconds in or 5 hours in. Where exactly do you find this VI? Was this your own? 

I'm pretty desperate to fix this on my machine also. I will try to use the Desktop Trace Execution toolkit.

This seems to be quite common - ActiveX seems to crash labview all the time. I can't believe NI has not noticed this or fixed it. 

[lemieuxcw]

The particular VI I was referencing was "Wait On ActiveX Event.vi", which turned out to be the problem.  This is an OLD VI that was packaged with LabVIEW up-to (I believe) LabVIEW ver 6.1.  It possibly existed in 7.0, but I'm not sure.  The code I had written (a subroutine specific to ActiveX processing) had this VI incorporated within it.  Over the years, up-conversions to newer versions of LabVIEW were successful (resulting in a cloned version of this VI being copied to some designated folder in the LabVIEW installation directory).  It wasn't until I attempted to use this VI on a 64 bit machine, embedded in an executable for distribution, did I see the real problem.

There is a solution - the LabVIEW examples refers to a call back function which can be used to achieve the same functionality.  It's much more efficient and best of all, it eliminated my problem.

If you have a hard time locating it (or implementing it), let me know - I can post an example.

Hope that helps.

-Chris

[pawel]

Juyst to update everybody on my crashing issue.

At the moment when I put all the Matlab calls into the conditional disable structure I no longer saw the crash for many weeks now. It is stable, I can work with the code as normal.

So if anybody have this issue, the answer is simple, do not use Matlab structure in LabVIEW. Translate to LV, or use dlls or exetuables, but using the Matlab script structure is responsible for months of pain I had.

[pobrepablo1]

hi chris,

I'm already using Register for events / callback functions. The bloody thing still gives me access violations. I'm ready to throw in the towel - it's like if sdk's are not not specifically tested on labview, theyre just going to crash.