Error Loading 'lvanlys.dll': Missing export 'SystemFuction036' from 'ADVAPI32.DLL'

[Claudio_G]

Just a typo correction

you can see that the one packeged by the labview build process is different than the one in the system folder

[xl600]

Is there any reason the build would be placing an invalid version of lvanlys.dll into the build (One that is different from the c:\ni-rt\system version)?  I'm seeing this same issue after migrating everything to LV2016 and LVRT 2016.

[xl600]

When I deploy my RT application (Source dist), it always includes a copy of lvanyls.dll.  The copy that gets deployed is on the left, while the copy that gets installed to c:\ni-rt\system is on the right.  There's no way this can be valid given that the product version is identical for both and there's a considerable size difference.  This looks like a pretty serious bug in LabView real time support needing immediate attention.

[Claudio_G]

Apart the size, if you analyze the PE headers, like with CFF explorer, you can see that the two libraries have a different set of imports. My guess is that one is used in a MS Windows deployment and the other is used for the RT deployment. However, I think the DLL shouldnt be exported to the "Data" folder at all, as both should already live in the respective system forlders (/Windows/System32 and /ni-rt-/system) as part of the Labview runtime.

[rolfk]

---

@Claudio_G wrote:

Apart the size, if you analyze the PE headers, like with CFF explorer, you can see that the two libraries have a different set of imports. My guess is that one is used in a MS Windows deployment and the other is used for the RT deployment. However, I think the DLL shouldnt be exported to the "Data" folder at all, as both should already live in the respective system forlders (/Windows/System32 and /ni-rt-/system) as part of the Labview runtime.

---

Your analysis that the DLL should not be copied to the data folder during build of the RT executable is most likely correct.

The reason that lvanlys.dll exists in two flavors has to do with the fact that for anything but the most trivial DLL, one has nowadays to build two different DLLs for use under Windows and the Pharlap ETS system used for LabVIEW RT, despite that Pharlap basically implements a Windows compatible loader. The reason is, that Pharlap API support is mostly stuck at the level of what Windows NT 4.0 provided (with a few features missing that make little sense to implement on a RT system).  If you take a modern C compiler it will simply create a DLL that is not anymore loadable on Pharlap ETS unless you go through loops and hoops to link it with a customized C runtime library, which is about as much fun as getting all your teeth pulled. But compiling with an old compiler for modern Windows versions is for many reasons also not a good idea anymore.

What apparently happened is that the build component that creates a runtime executable got changed in 2016 and somehow the fact that lvanlys.dll should not be included in the build for an RT executable because it is already provided by the RT system on the target got lost. Instead it copies the lvanlys.dll that is normally used for Windows builds into the build target.

[xl600]

What I'm seeing is that there seems to be more than two flavors.  The one in ni-rt, the Windows flavor, and something else entirely that is getting copied into the build (That doesn't seem to be a copy of anything).  Had the copied version been the same size as the ni-rt/system version, I wouldn't really have any issue I'm sure and would just be facing redundant copies of the same DLL.  But the copied version is much smaller than even the RT version in ni-rt/system (Which doesn't really make sense if that was simply the full windows copy).

[RenKylo2]

Hi Everyone,

I want to share some thoughts on this particular dll. Rolf and Claudio are on the right track here.

RT build specifications do not deploy certain libraries on purpose, even though they might be included in the build. When deploying using the LabVIEW development environment, the deployment checks to see if here are any startup libraries that the RT system already uses and removes those libraries from the deployment.

lvanlys.dll is one of those libraries. Like everyone has mentioned, there is a version on the RT target, which is specifically compiled for RT. The RT dll is installed on the RT OS is installed. The dll that comes with the build is the Windows version.

If the RT build spec was deployed from the LabVIEW project, the dll should not copy over to the RT target. I verified this in LabVIEW 2015, 2016 and 2017. In LabVIEW 2017, the dll was not included in the build at all.

If you are using 2016 and manually copy over (such as FTP) the dll to the c/ni-rt/startup/data folder, you will see the the systemfunction error message. It seems for whatever reason, the 2016 version contains systemfunction036, which is not support in PharLap. It should not stop the RT EXE from executing properly. Take a look at this KB. It has an executable attached that you can verify if a dll can be used in PharLap. If you run it on the 2016 version of the dll that comes with the build, systemfunction036 should show up as a Bad Import. 

[xl600]

I get the sense that the version that is put into the RT build sources is not the Windows version, but a redacted version of the RT version.  For example, when building, the app builder removes non RT functions from the RT DLL that it feels aren't needed for the specific build.

In LV2016, this process seems to go wrong and SystemFunction036 is left in that build specific DLL version.

So, there's three versions of the DLL.

1.  The original redacted DLL for RT containing ALL functions compatible with the RT system placed in c:\ni-rt\system.

2.  The master DLL (Windows, containing everything) located on the Windows machine.

3.  A build specific redacted DLL containing only functions necessary for the build

The build specific DLL seems redundant, but kinda makes sense if the build is meant to have back compatibility or whatever (If the Windows RT version differs from the installed RT version on the RT controller).

Regardless, this is a bug and from what support tells me, 2017 doesn't seem to have this problem.  I can't upgrade for about 6 months (Project budget, schedule, and configuration control driven) so I'm going to just delete the DLLs from my builds using my custom build tool.  That should work fine since I always make sure my RT version matches the controller's RT version (Which is the recommended way to go by support).

[NancyfromGD]

I am using LabView 2017 and I am having this same problem. The lvanlys.dll is included as a dependency when I build my PPL but when I go to deploy it says the file is not located - even though it is in the same directory as the other support DLLs. What can I do to get around this problem. The Deploy Build fails. I tried removing it from the support directory and the deploy build is still looking for it and still fails. Any suggestions?