Exception: Access violation (0xC0000005) at EIP=0x00000000309F9CA0

[nikodem]

I have encountered this error in my VI.

I'm trying to make a set of VIs for building my packed library, updating the references in my TestStand sequence for this packed library (from the unpacked one) and making an installer out of it (the sequence and lvlibp).

In order to programmatically update the references in the seq I'm editing the .seq file first (as a normal text file) to change the paths etc. and then I'm reloading the prototypes in the sequence using the VI shown below:

During the execution of this VI I encounter Access violation (0xC0000005) at EIP=0x00000000309F9CA0 which crashes my LabView. The exception happens during the execution of the TS.Module.LoadPrototype method.

The problem is, that if I run this VI separately nothing happens. Only if it is run in the VI that is calling the subVI in order to build the lvlibp, change the sequence, make the installer etc...

[Bob_Schor]

Do you expect us to see this image?  Try attaching the actual VI, which allows us to closely examine the code (including anything "hidden" in other Cases, see which version of LabVIEW you are using, maybe even trying to run the code and seeing where the error pops up.

Bob Schor

[nikodem]

No problem with that, although I don't know if you will be able to replicate my problem without the whole environment in which I run this VI, the project etc.

[billko]

---

@Bob_Schor wrote:

Do you expect us to see this image?  Try attaching the actual VI, which allows us to closely examine the code (including anything "hidden" in other Cases, see which version of LabVIEW you are using, maybe even trying to run the code and seeing where the error pops up.

Bob Schor

---

It's a real snippet.

[nikodem]

Yes, it is a snippet, and other cases are empty (nothing happens there, just passing the error cluster).

Moreover - by running this VI you will not be able to replicate thus exception, as running it ALONE does not trigger any kind of access violation; it happens only when this VI is used as subVI.

The whole app looks like so:

First build block is responsible for packing an library, next the two blocks between the elapsed time VIs are responsible for:

First: changing the paths in our TestStand sequence from the lvlib on which we work (in developer version) to lvlibp for the release.

Second: updating the VIs prototypes in the sequence, and this is the place, where the exception occurs.

Funny thing is, that when you run these subVIs separately, manually trigger them one by one everything runs smoothly. but as soon as I run the VI shown above it crashes at the first time it calls the TS.Module.LoadPrototype method.

I was thinking that maybe it is because of some handler issues, after the build. I'm triggering the builder using NI App Builder API Build.vi in the first subVI, so maybe it has got some handlers that are not released properly? This is why I inserted the App.ClearCompObjCache and App.ClearAppBuilderCache methods, but this didn't help and I have no other idea how to check if this is an handler issue or what.

[nikodem]

So in the mean time I'm trying to understand what is happening and what could be done to make this app work properly.

First I've tried to put in the build subvVI all possible VIs and methods with 'clean' in the name 😉 resulting in this:

Of course it didn't help. I've also experimented with making this and/or the VI responsible for updating the prototypes in the TS sequence reentrant. Also it didn't help, it still gives me the same access violation exception.

Then, I've came with an idea (actually a friend of mine came with this idea) - lets make a copy of the lvlibp and use the copy in seq. At first it seemed great, but unfortunately - nope, it seems you cannot rename a packed library, because then there are some problems with paths inside the file, and some dependencies are braking and subVIs are not called properly... Maybe it's my fault that I can't configure the build to implement a packed-library-name-agnostic structure, but still this idea was also scrapped. And for now we have no further ideas.

[nikodem · Accepted solution]

Okay, so I think I found the solution for my problem, but is not the perfect one I guess... I have uninstalled NI LabView 2015 Runtime that I had on my PC  why? just randomly, it didn't look okay, as I use LV 2014... not the most elegant solution, I agree. Now the VIPM is not working, but this is a minor problem. 

But there is another issue. How to force TestStand Engine to use a specified LV version? PROGRAMMATICALLY. I know that you can configure the adapters manually, but I need my builder doing this automatically. Is it possible?

[natasftw]

The expression you'll want is in this KB: http://digital.ni.com/public.nsf/allkb/C078C4325CD2287D8625725F007CC49F?OpenDocument

Are you looking at the full dev environment or the RTE?  It's a bit more challenging to use the dev environment.

[.aCe.]

Here is a LabVIEW implementation: http://forums.ni.com/t5/NI-TestStand/Configure-LabVIEW-Adapter-Programmatically/td-p/3504100

[nikodem]

Thank you, this was exactly the thing that I was searching for.