Tracking down an Access violation

[BowenM]

I've spent several hours trying to track down an access violation.  No luck!  So I'm looking for anything I haven't tried.

The symptoms:

Application runs and stops fine in development.  Never had an access violation.  Once the exe is built when I shutdown the application I get an access violation.  I added in some debug stuff and all of my threads so end up stopping correctly.  Once I handle any final errors I check that App.Kind == Run Time System.  If true, I execute the "Quit LabVIEW" function.  At this point in time I get an access violation.

Things I've tried:

--Adding diagram disable structures around entire sections of code that I think might be causing problems. No luck.

--Added all the debug calls in to verify all of my threads had stoped execution correctly.

--Went through and made sure I had closed all of my "important" references.

So, any suggestions on debugging?  Because all of my threads stop execution correctly it is really more of an annoying thing than critical but it just looks bad to give an application to my customers that crashes when closed...

[Bob_Schor]

The "Quit LabVIEW" function stops LabVIEW (the Development System), which (probably) isn't running if you are running a built Executable!

Plus why bother doing this?  If your program closes everything else, you can ask it to close its own Front Panel as the "last thing it does", then there's nothing else you need to do.

Bob Schor

[BowenM]

Quit LabVIEW does the same thing in runtime as it does in development:  shuts down all executing VIs and closes the environment.  At this point in time all of my main loops have stopped execution.  I do however have multiple asynchronous GUIs that are not critical... simple things like data plotting, etc.  No data save, no need to gracefully shutdown.  In these cases I am happy to just let Quit LabVIEW stop execution and close the front panel.

Disabling Quit LabVIEW and just closing front panel however is something I hadn't thought of to try for debugging 🙂

[Alexander_Sobolev]

It seems like a race condition in releasing resources by improper releasing them. My guess is that abort VI (quit labview = abort all VIs, see help) kills memory associated with it, or common with some system windows, etc. VIs may be stopped, but he is still loaded and is occupying resources. LabVIEW is trying to clean up in parallel, and that already does not belong to it. 

Anyway, closing VIs normally should fix it.

[BowenM]

---

Alexander_Sobolev wrote:

Anyway, closing VIs normally should fix it.

---

Thanks for your response.  After Bob's comment I modified it to not rely on the "Exit LabVIEW" call.  As I suspected this wasn't the problem.  Everything seems to stop execution fine and the violation only happens once the engine tries to shutdown.

I've gone through all of the main sections of the application to make sure queues, references, etc are being released correctly.  No luck so far... 

I'm also not looking for a specific solution.  Unfortunately the application is over 1k VIs and my guess is that the problem is something silly buried somewhere deep.  I'm more hoping for "here are some methods for troubleshooting this you can try"!

[Jacobson-ni]

If you have some crash dumps I would be willing to take a look through some to see if we can link it to a CAR or point to some specific section of your application.

In terms of troubleshooting something like this, I'm not sure how the application is structured but if you have a lot of separate processes that you have to close down I would possibly see if you could very slowly shut things down one at a time (maybe wait a few seconds in between sending shutdown messages to different processes) and see if it's a specific processes that is causing this.

I'm not sure why this would be different in an exe but I have also seen problems crashing at the end of an application if you are calling into a dll with the clfn because that is when it will unload usually. I've seen different reasons for this but it has the same symptoms of everything stops and then you crash.

[rolfk]

Another possible culprit might be some Call Library Node that is not configured right or does call a function that is performing a buffer overrun or some other illegal operation. The fact that it runs in the development environment is not only not a guarantee that you don't have such a problem in your app, but in fact rather an extra indication that it might be such a problem.

I've made a lot of shared libraries and interfaced them to LabVIEW with the Call Library Node and have seen many cases where an error in the shared library or the Call Library Node configuration did exactly cause such problems. Violating memory can sometimes cause an immediate crash but often it goes undedected until the application closes and when trying to cleanup and deallocate all resources, stumbles over the corrupted pointers and crashes.

Memory layout may make that the corruption happens in some more or less important part that may or may not cause a crash at some point. It's quite clear that an application run in the IDE has a rather different memory layout than one run in the runtime system.

[BowenM]

Thanks for the responses.  I got busy and lost track of the thread.

Matt:   Thanks for the offer.  I spent several more hours troubleshooting and thought I'd pinpointed it to my TestStand module... if I would execute a TS sequence file programmatically and then shutdown I would get the access violation.  No execution = no access violation.  However, I then took just that module and compiled it wouthout the main application and of course I couldn't get it to crash.  I did finally give up and call NI for an applications engineer to verify I wasn't doing anything stupid in my code. I was told I wasn't.

As for shutting down the code one process at a time - they all shutdown correctly.  The very last thing I do is merge errors from all of my threads and log them to disk.  It gets all the way through the log and I only get the access violation as the actual LabVIEW runtime environment is shutting down.

Rolf:  I've seen this issue with the Call Library Node before as well.  The only instance of that I have in my application is a call to User32.dll and it is working correctly.  Completely disabling that section (it is part of my hardware I/O module) has no impact on the access violation. 

I am however making calls to several .net libraries.  I can go through those sections of code and try disabling them one at a time until I'm either out of options to disable or until I find my violation.