LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Access violation (0xC0000005). Why, and can I just delete the offending code?

Solved!
Go to solution

I've run into problems beyond my debugging abilities and am not sure how to resolve this.

 

I run my project, it gets to the point where a certain vi is closing itself and labview crashes. 

Previously it was giving the submit crash report window (i submitted one) and this code: Access violation (0xC0000005) at EIP=0x01232FF1

Now it just crashes without the report window.

 

The vi writes an image to my class data, and when i disable that vi, the project doesn't crash. Originally it had no broken arrows, then following a mass recompile it did, but the error list gave no more insight as to why.

errors.png

 

Now it doesn't have broken arrows again anymore (dont think i did anything), but it still crashes.

 

This morning I did make some controls into typedefs that weren't originally, and I replaced some of the class private data controls with these. But I've since gone through and resaved them all (suggested in another thread) and it didn't seem to help.

 

Part of me feels like it'd be simple to just delete this vi and pass the data in once the actor launches. Can I just do that? I suspect that's not fixing the issue though, and I don't want it to happen again. 

 

Can i go back to an old version of this class? It all ran fine when i tested it last week before making other changes. Again I don't know if that's just cheating round the problem.

 

Can anyone advise on what I should do?

 

I've attached the project folder and in it the DETs that I ran. (LV20, Launcher vi is in the 'external tree' virtual folder. Running the project will crash your labview)

 

Here's the DET, the offending VI and it's calling vivis.pngdet.png Thanks in advance for any help

0 Kudos
Message 1 of 4
(2,268 Views)

That's a pretty serious error and low level too. There is very little one can say about it other than that your application tried to access illegal memory.

 

You mention that disabling that VI seems to get rid of the crash but I think that is just a red herring. Where do you get that image from? From NI IMAQdx or some custom frame grabber library? There is a good chance that the damage is done when filling in the data into the image already and the crash simply occurs when LabVIEW later tries to access that corrupt memory. 

 

If the image is not stored into the image from NI IMAQdx but something else you definitely and positively should start to look there. Memory Management in LabVIEW is something you don't normally have to worry about, except when you start to access DLLs and especially if these DLLs deal with large memory buffers, which images always are. You can't just take the memory pointer of an IMAQ control and pass it to a DLL to write data into it. Before that you have to make sure the image is sized correctly with height and width and also the right pixel format. Only after that are you save to call the Map Pixel Pointer function and you should make sure that the IMAQ wire does not go through other nodes that might modify the image while your DLL call is executing.

Rolf Kalbermatter
My Blog
0 Kudos
Message 2 of 4
(2,218 Views)

Hi Rolf, thanks for your response. 

 

The image just comes from a snap taken by the camera using IMAQdx. So the call chain (minus the message vis) is below. The photo is taken, sent to a method which uses an accessor to add it to the class private data and then launches the actor. It feels innocent enough. The crash occurs at the middle vi which adds the 'image' to the data. I added a trace to the crashing vi following the bundle, and that executed, so it seems it is occurring on the close of the vi as the det suggests (maybe that makes sense). 

snap.png

vis.png

 

Could be worth mentioning that the camera is currently the webcam of my computer, but it always has been and once I disable the bit that crashes it's still able to return images in other parts of the program. 

 

I've never worked with vision before so there's every chance I've gotten something wrong here, but I didn't think I was doing things too differently than the simple vision examples which I copied

0 Kudos
Message 3 of 4
(2,189 Views)
Solution
Accepted by topic author Shiv0921

Coming back to this after all this time because I never fedback and perhaps this could help someone with the same problem as this was an awful one to get to the bottom of, even with NI's help.

I forget the details, in the end it was something to do with changing the owning class of one of the typedefs, but crucially NI suggested reinstalling LabVIEW with the most up to date patches (I was a patch or two behind at this point), and this solved the problem. I was able to work with the same code and never had the access violation again. Apparently keeping LabVIEW as up to date as you can is a good first port of call to unusual issues like these. 

 

Message 4 of 4
(411 Views)