03-20-2013 01:09 PM
Have you confirmed beyond a doubt that the ActiveX/COM object is the culprit? Meaning, have you removed all calls to your object and performed tests beyond that? This Access Violation error is a terrible thing to debug - I know exactly the frustration you're dealing with. You'd be surprised what you 'might' think it is and it end up being something completely (seemingly) unrelated. When I encountered my issues, I was certain my problem was more to do with a USB-Serial adapter.
If you have nothing proprietary in your code, you could either post it here for review or email it to me and I can look it over for anything that might stand out.
03-20-2013 02:10 PM
I definitely would not assume its a 3rd party software issue. There is, without a doubt, a bug in LV2011 that causes memory access violations. I have been using the same code for 7 years in LV 7.1, 8.x and 2010 with not a single memory access violation. Once switching to LV2011 32 bit and Windows 7 Pro 64bit these errors started popping up. I dont have any ActiveX, antivirus software or 3rd party DLLs or anything weird - just basic LabVIEW stuff that has been stable for years. Starting with LV2011, I get these memory access violations from time to time (once every couple months) and its a huge problem. You just cant trust LabVIEW anymore. NI has been no help in resolving the issue. Of course they will try to blame it on other software (antivirus, etc...) but the problem is with LabVIEW itself. Also, now I am unable to revert from LV2011 back to LV2010 - it gives an error when I try to resave it for on older version and I have tried everything. NI, if you are listening, please help!!
03-20-2013 02:18 PM - edited 03-20-2013 02:24 PM
Chris,
I'm fairly certain it is the activeX. The main program will just idle there, waiting for events, and it will die - and the only thing active in such a case is the activeX callback VIs.
I really appreciate your offer to help. I've attached my VI. The 3rd party sdk can be installed as a trial... http://www.ab-soft.com/download/ActiveDcamSetup.exe It's pretty uninstrusive, and you can uninstall it right away. Actually you may not even need it if the VI opens, so check that first.
If you have 64-bit labview this VI crashes immediately if the camera is not found (assuming the control loads)
Let me know if you see any glaring issues. Some globals are used; their purpose is to allow the user to draw a rectangle on the image.
The main VI is in Users/paul14/Desktop/CameraTester.Vi. Its a chunk of code taken from a much larger project.
Edit: I realize in my event structure, I have a missing wire in the stop case. That was a recent addition, just ignore that
03-20-2013 02:45 PM
Quick question - do you encounter the same issue whether this is running from source or built application? I'll get a look this evening and see what I can find.
03-20-2013 02:51 PM
CandyAndy,
I am sorry to hear that you have been having these problems and about your current trust in LabVIEW. Rest assured that NI attempts to help resolve these errors whenever they are thrown, and we can start to assist you if you would post your code to the forums so that we can attempt to replicate the error.
But please keep in mind that this error is a generic Windows error and as research will show, it is very difficult to identify the source of it. The error can be thrown by Windows for a very large variety of reasons, including the 3rd party DLLs, ActiveX, or Matlab, which make up the very large majority of sources.
If you have been unsatisfied with our support in resolving this issue, then please feel free to call in to our support line at (866) 275-6964 in order to make a service request and to speak with an Applications Engineer.
03-20-2013 03:40 PM - edited 03-20-2013 03:40 PM
Chris,
I get the error in both cases, but it seems the built exe has the problem more frequently.
But If you install the ab software first (ensuring the control will load), and load the VI using a 64-bit version of labview, it will immediately crash when it loads.
03-20-2013 03:55 PM
But If you install the ab software first (ensuring the control will load), and load the VI using a 64-bit version of labview, it will immediately crash when it loads.
This doesn't sound promising, and certainly indicates a conflict between the 32-bit dll/ocx and the 64-bit development environment. I'm curious, does the third party supplier (AB) offer an application of thier own? Typically they do. If so, I'm curious if you're able to perform similar functions (even if it's mostly manual) via their application on the same target machine (removing LV from the picture altogether).
03-20-2013 04:19 PM - edited 03-20-2013 04:22 PM
They do provide a 64bit app, and it works OK. All their sample apps are fine. None of their samples are in labview.
It's very curious because the 64bit control will be OK until... the first time it is used.
Here's what happens. I create the ActiveX container. Insert the dcam control. Note that a this point I haven't connected any cameras; it will be fine. I can load and unload the VI all i want, 64bit or 32bit.
The first time I load the Vi with a camera attached, it sees the camera, it will run fine. it will run fine on all subsequent loads. BUT, if you now open this VI without the camera being connected - bam, access violation, every single time.
it is as if it is looking to read from the camera when it's not there.
I can restore my VI by either connecting the camera, or by loading the VI in 32bit mode, deleting the control, and reinserting it.
None of this "bad stuff" occurs in 32bit mode. Nothing of the sort happens in, for example, vb.net, or matlab or anywhere else.
03-20-2013 04:46 PM
Huntington,
Unfortunately, the code only gives the access violation every couple of months of continuous operation. I'm looking for suggestions on areas in LabVIEW 2011 that have known problems so I can systematically test the various parts of my very large application and hundreds of sub VIs. So far, from the forums it seems there may be bugs in LabVIEW 2011 related to one or more of the following:
Build Array
Append to Text File
Call VI by Reference Node
Running LV 32 bit .exe files on 64 bit Windows 7
I have been trying to test these, but so far have not been able create a test VI that gives an Access violation with a high enough frequency to reproduce the error or even create a single access violation. Several years ago I faced a similar problem with an undocumented bug in LabVIEW 7.1 related to the queue VIs in LabVIEW when running on multiprocessor machines. It crashed only every week or so in my application, but once I figured out what was causing it, I could create a VI that crashed within a few seconds every time. Hopefully I'll be able to find this bug the same way.
Im looking for suggestions from NI to try to pin this down. Also, I was told by an NI engineer on the phone that these memory access violations are new to LabVIEW 2011 since there have been a large number of reports from users of LV2011 but almost no reports from LV2010.
Thanks,
Andy
05-24-2013 03:14 AM
Hey Martin D
Is it possible for you to send an example vi, I have tried the same method, but LV gives me an Access violation (0xC0000005) error when I passes the struct to a method.
Best regards