LV7.1 stops with a pop-up stating "LabVIEW: External code not presen. VI "Main.vi" was stopped at node 0xD60 of subVI ..."

[LuI]

Hi all,

I have a rather large project which includes some subVIs that call a dll named 'bl.dll'. Recently we where able to make bl.dll reentrant, which allowed me to change all dll-calls to 'reentrant execution'. Afterwards allmost all (if not literally all) subVIs calling bl.dll show this STOP error until I re-point the node to bl.dll.
The confiburation still points to bl.dll and the subVIS are still executable and the called functions are still there. But this STOP shows up for each subVI at least once. Any ideas?

Don't instruct me to update LV as this projject is almost ready and at least this part of the app worked just fine all the time.

Can this be caused by a new version of bl.dll? Again, I just exchanged the dlls when LV was not in RAM. AND all functions are still there.
Bl.dll itself loads and calls some other dlls dynamically. Those are present as well. Can this cause the problems _now_?

Greetings from Germany!
--
Uwe

[Jochen]

I don't think that the issue is caused by a secondary dll called by bl.dll because in this case the error message would be different. Can you reproduce this issue with a small example that you could post here? What happens if you switch back from "Reentrant Execution" to "Runi in UI thread"? Does the issue still exist?

Best regards,

Jochen Klier
National Instruments Germany

[LuI]

Jochen,

thanx for the answer.
I _think_ this is a problem related to the search pathes, that might have been temporarily changed using a file browse control or so.
The very same project, when copied onto a different machine, runs smoothly, so posting here would probably not help.
And this issue came up first when I changed from 'reentrant' to 'UI-thread', just to test if some other problems might be caused by rentrancy problems.

Let me explain the situation more precisely:
I have a project directory where I do the devellopment, which is "c:\getemed\testsystem\vg3100\".
This directory contains the whole project including all vi's, ctl's, vit's and dlls. And than there's a documentation directory, that contains all automatically created report.doc's and the Reporttemplate.dot. This is at "d:\getemed\testreports\". And a third directory for kind of debug logs, which is in a subdir of the latter directory.
There are some path constants and a (normally invisible) path control with a default path and the 'browse' button visible. Maybe I have unintentionally changed the search path during some tests?

Any ideas?

Meanwhile I'll run the project and fix all those calls until all are repaired ;-((

Greetings from Germany!
--
Uwe

Message Edited by LuI on 05-10-2006 11:24 AM

[LuI]

Just a follow-up:
The problem worsened much:
http://forums.ni.com/ni/board/message?board.id=170&message.id=185147

I seem to have it fixed now, allthough I feel like magic, somehow. This is the solution:
Finally I replaced all wrapper VI (those that actually call the dll) with a backuped version that was about 10 days old.
And I replaced the dlls, which had been debug version up to now, with release versions.
I am not clear which action did the trick, but now my system is running again :-))

Greetings from Germany!
--
Uwe