Failure to load frontend.dll during logout

[snowpunter]

We've recently started seeing this error on a few of our benches when exiting our operator interface after executing our sequence. This error does not occur if the user logs in to the OI, does not run our sequence and then exits the OI. If 'Retry' is pressed the error does not repeat.

A few details:

TS 4.1.1

LV Runtime 8.6.1

Standard OI

We do have a custom process model but it is only adding a Execution Entry Point for configuring the bench and has Single Pass renamed to Execute Test.

As this only occurs if we run our sequence what could I be doing in the MainSequence that is screwing this up? Search directory issues? Anyone have any thoughts?

[asbo]

A small sanity check: C:\Program Files\National Instruments\TestStand 4.1.1\Components\Callbacks\FrontEnd\frontend.dll does exist on disk, correct? The fact that retrying does not repeat the error makes me think so, but it's always good to rule out the easy things 🙂

Does your sequence modify the search directories on the fly? Pull open FrontEndCallbacks.seq and see how LoginLogout is looking up that DLL. Throw a breakpoint at that step and see how it executes.

Does this present if using the Sequence Editor (or is that what you meant by "Standard OI")?

[snowpunter]

Frontend.dll is there but thanks for the check 😉

The Logout call loads the frontend.dll dynamically. We are not making any calls to dynamically change the search directories, and very few Engine calls in general.

This does not happen at all with the source in the sequence editor. However, once I create an Image/Installer with the deployment utility I can open up the Image build in the seq editor and reproduce the issue (changing the search directories to use the Image path first) and on every deployed system we've tested this with. We are not deploying the TS Engine (that occurs with a seperate deployment that hasn't changed in a year)

So basically once I use the .seq/files that have been run through the utility this issue occurs. I've got a support ticket in for this as well and I'll post once we find the resolution. Truly a bizarre issue.

[asbo]

Very interesting. The knee-jerk reaction here is obviously to blame the deployment process - I haven't dabbled much in that so far, so I don't know if it's still possible to troubleshoot your deployment LoginLogout sequence like I described. If you can, that's definitely what I would check next. Logic dictates that if you set that step to break and prod around (put its path expression into the watch view, for example) it should kick back an invalid path on the first evaluation. Maybe that will help shine some light on what's happening.

[snowpunter · Accepted solution]

The issue was a call library function node that contained an absolute path to C:\Windows\System32\kernel32.dll instead of a relative path. Once a relative path was used the error went away.